This is a note to let you know that I've just added the patch titled
dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
to the 4.14-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:
dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Wed, 8 Nov 2017 12:02:25 +0200
Subject: dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit 288e7560e4d3e259aa28f8f58a8dfe63627a1bf6 ]
The used 0x1f mask is only valid for am335x family of SoC, different family
using this type of crossbar might have different number of electable
events. In case of am43xx family 0x3f mask should have been used for
example.
Instead of trying to handle each family's mask, just use u8 type to store
the mux value since the event offsets are aligned to byte offset.
Fixes: 42dbdcc6bf965 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/ti-dma-crossbar.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -49,12 +49,12 @@ struct ti_am335x_xbar_data {
struct ti_am335x_xbar_map {
u16 dma_line;
- u16 mux_val;
+ u8 mux_val;
};
-static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u16 val)
+static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
{
- writeb_relaxed(val & 0x1f, iomem + event);
+ writeb_relaxed(val, iomem + event);
}
static void ti_am335x_xbar_free(struct device *dev, void *route_data)
@@ -105,7 +105,7 @@ static void *ti_am335x_xbar_route_alloca
}
map->dma_line = (u16)dma_spec->args[0];
- map->mux_val = (u16)dma_spec->args[2];
+ map->mux_val = (u8)dma_spec->args[2];
dma_spec->args[2] = 0;
dma_spec->args_count = 2;
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.14/dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch
This is a note to let you know that I've just added the patch titled
dev/dax: fix uninitialized variable build warning
to the 4.14-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:
dev-dax-fix-uninitialized-variable-build-warning.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Date: Wed, 18 Oct 2017 12:21:55 -0600
Subject: dev/dax: fix uninitialized variable build warning
From: Ross Zwisler <ross.zwisler(a)linux.intel.com>
[ Upstream commit 0a3ff78699d1817e711441715d22665475466036 ]
Fix this build warning:
warning: 'phys' may be used uninitialized in this function
[-Wuninitialized]
As reported here:
https://lkml.org/lkml/2017/10/16/152http://kisskb.ellerman.id.au/kisskb/buildresult/13181373/log/
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dax/device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -222,7 +222,8 @@ __weak phys_addr_t dax_pgoff_to_phys(str
unsigned long size)
{
struct resource *res;
- phys_addr_t phys;
+ /* gcc-4.6.3-nolibc for i386 complains that this is uninitialized */
+ phys_addr_t uninitialized_var(phys);
int i;
for (i = 0; i < dev_dax->num_resources; i++) {
Patches currently in stable-queue which might be from ross.zwisler(a)linux.intel.com are
queue-4.14/dev-dax-fix-uninitialized-variable-build-warning.patch
This is a note to let you know that I've just added the patch titled
crypto: tcrypt - fix buffer lengths in test_aead_speed()
to the 4.14-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:
crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Robert Baronescu <robert.baronescu(a)nxp.com>
Date: Tue, 10 Oct 2017 13:22:00 +0300
Subject: crypto: tcrypt - fix buffer lengths in test_aead_speed()
From: Robert Baronescu <robert.baronescu(a)nxp.com>
[ Upstream commit 7aacbfcb331ceff3ac43096d563a1f93ed46e35e ]
Fix the way the length of the buffers used for
encryption / decryption are computed.
For e.g. in case of encryption, input buffer does not contain
an authentication tag.
Signed-off-by: Robert Baronescu <robert.baronescu(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/tcrypt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -340,7 +340,7 @@ static void test_aead_speed(const char *
}
sg_init_aead(sg, xbuf,
- *b_size + (enc ? authsize : 0));
+ *b_size + (enc ? 0 : authsize));
sg_init_aead(sgout, xoutbuf,
*b_size + (enc ? authsize : 0));
@@ -348,7 +348,9 @@ static void test_aead_speed(const char *
sg_set_buf(&sg[0], assoc, aad_size);
sg_set_buf(&sgout[0], assoc, aad_size);
- aead_request_set_crypt(req, sg, sgout, *b_size, iv);
+ aead_request_set_crypt(req, sg, sgout,
+ *b_size + (enc ? 0 : authsize),
+ iv);
aead_request_set_ad(req, aad_size);
if (secs)
Patches currently in stable-queue which might be from robert.baronescu(a)nxp.com are
queue-4.14/crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch
This is a note to let you know that I've just added the patch titled
clk: tegra: Use readl_relaxed_poll_timeout_atomic() in tegra210_clock_init()
to the 4.14-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:
clk-tegra-use-readl_relaxed_poll_timeout_atomic-in-tegra210_clock_init.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Nicolin Chen <nicoleotsuka(a)gmail.com>
Date: Fri, 15 Sep 2017 12:10:13 -0700
Subject: clk: tegra: Use readl_relaxed_poll_timeout_atomic() in tegra210_clock_init()
From: Nicolin Chen <nicoleotsuka(a)gmail.com>
[ Upstream commit 22ef01a203d27fee8b7694020b7e722db7efd2a7 ]
Below is the call trace of tegra210_init_pllu() function:
start_kernel()
-> time_init()
--> of_clk_init()
---> tegra210_clock_init()
----> tegra210_pll_init()
-----> tegra210_init_pllu()
Because the preemption is disabled in the start_kernel before calling
time_init, tegra210_init_pllu is actually in an atomic context while
it includes a readl_relaxed_poll_timeout that might sleep.
So this patch just changes this readl_relaxed_poll_timeout() to its
atomic version.
Signed-off-by: Nicolin Chen <nicoleotsuka(a)gmail.com>
Acked-By: Peter De Schrijver <pdeschrijver(a)nvidia.com>
Signed-off-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/tegra/clk-tegra210.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/clk/tegra/clk-tegra210.c
+++ b/drivers/clk/tegra/clk-tegra210.c
@@ -2566,8 +2566,8 @@ static int tegra210_enable_pllu(void)
reg |= PLL_ENABLE;
writel(reg, clk_base + PLLU_BASE);
- readl_relaxed_poll_timeout(clk_base + PLLU_BASE, reg,
- reg & PLL_BASE_LOCK, 2, 1000);
+ readl_relaxed_poll_timeout_atomic(clk_base + PLLU_BASE, reg,
+ reg & PLL_BASE_LOCK, 2, 1000);
if (!(reg & PLL_BASE_LOCK)) {
pr_err("Timed out waiting for PLL_U to lock\n");
return -ETIMEDOUT;
Patches currently in stable-queue which might be from nicoleotsuka(a)gmail.com are
queue-4.14/clk-tegra-use-readl_relaxed_poll_timeout_atomic-in-tegra210_clock_init.patch
This is a note to let you know that I've just added the patch titled
clk: tegra: Fix cclk_lp divisor register
to the 4.14-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:
clk-tegra-fix-cclk_lp-divisor-register.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
Date: Tue, 19 Sep 2017 04:48:10 +0200
Subject: clk: tegra: Fix cclk_lp divisor register
From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
[ Upstream commit 54eff2264d3e9fd7e3987de1d7eba1d3581c631e ]
According to comments in code and common sense, cclk_lp uses its
own divisor, not cclk_g's.
Fixes: b08e8c0ecc42 ("clk: tegra: add clock support for Tegra30")
Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
Acked-By: Peter De Schrijver <pdeschrijver(a)nvidia.com>
Signed-off-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/tegra/clk-tegra30.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -964,7 +964,7 @@ static void __init tegra30_super_clk_ini
* U71 divider of cclk_lp.
*/
clk = tegra_clk_register_divider("pll_p_out3_cclklp", "pll_p_out3",
- clk_base + SUPER_CCLKG_DIVIDER, 0,
+ clk_base + SUPER_CCLKLP_DIVIDER, 0,
TEGRA_DIVIDER_INT, 16, 8, 1, NULL);
clk_register_clkdev(clk, "pll_p_out3_cclklp", NULL);
Patches currently in stable-queue which might be from mirq-linux(a)rere.qmqm.pl are
queue-4.14/clk-tegra-fix-cclk_lp-divisor-register.patch
This is a note to let you know that I've just added the patch titled
clk: mediatek: add the option for determining PLL source clock
to the 4.14-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:
clk-mediatek-add-the-option-for-determining-pll-source-clock.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Chen Zhong <chen.zhong(a)mediatek.com>
Date: Thu, 5 Oct 2017 11:50:23 +0800
Subject: clk: mediatek: add the option for determining PLL source clock
From: Chen Zhong <chen.zhong(a)mediatek.com>
[ Upstream commit c955bf3998efa3355790a4d8c82874582f1bc727 ]
Since the previous setup always sets the PLL using crystal 26MHz, this
doesn't always happen in every MediaTek platform. So the patch added
flexibility for assigning extra member for determining the PLL source
clock.
Signed-off-by: Chen Zhong <chen.zhong(a)mediatek.com>
Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/mediatek/clk-mtk.h | 1 +
drivers/clk/mediatek/clk-pll.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -216,6 +216,7 @@ struct mtk_pll_data {
uint32_t pcw_reg;
int pcw_shift;
const struct mtk_pll_div_table *div_table;
+ const char *parent_name;
};
void mtk_clk_register_plls(struct device_node *node,
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -303,7 +303,10 @@ static struct clk *mtk_clk_register_pll(
init.name = data->name;
init.flags = (data->flags & PLL_AO) ? CLK_IS_CRITICAL : 0;
init.ops = &mtk_pll_ops;
- init.parent_names = &parent_name;
+ if (data->parent_name)
+ init.parent_names = &data->parent_name;
+ else
+ init.parent_names = &parent_name;
init.num_parents = 1;
clk = clk_register(NULL, &pll->hw);
Patches currently in stable-queue which might be from chen.zhong(a)mediatek.com are
queue-4.14/clk-mediatek-add-the-option-for-determining-pll-source-clock.patch
This is a note to let you know that I've just added the patch titled
clk: imx: imx7d: Fix parent clock for OCRAM_CLK
to the 4.14-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:
clk-imx-imx7d-fix-parent-clock-for-ocram_clk.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Adriana Reus <adriana.reus(a)nxp.com>
Date: Mon, 2 Oct 2017 13:32:10 +0300
Subject: clk: imx: imx7d: Fix parent clock for OCRAM_CLK
From: Adriana Reus <adriana.reus(a)nxp.com>
[ Upstream commit edc5a8e754aba9c6eaeddd18cb1e72462f99b16c ]
The parent of OCRAM_CLK should be axi_main_root_clk
and not axi_post_div.
before:
axi_src 1 1 332307692 0 0
axi_cg 1 1 332307692 0 0
axi_pre_div 1 1 332307692 0 0
axi_post_div 1 1 332307692 0 0
ocram_clk 0 0 332307692 0 0
main_axi_root_clk 1 1 332307692 0 0
after:
axi_src 1 1 332307692 0 0
axi_cg 1 1 332307692 0 0
axi_pre_div 1 1 332307692 0 0
axi_post_div 1 1 332307692 0 0
main_axi_root_clk 1 1 332307692 0 0
ocram_clk 0 0 332307692 0 0
Reference Doc: i.MX 7D Reference Manual - Chap 5, p 516
(https://www.nxp.com/docs/en/reference-manual/IMX7DRM.pdf)
Fixes: 8f6d8094b215 ("ARM: imx: add imx7d clk tree support")
Signed-off-by: Adriana Reus <adriana.reus(a)nxp.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/imx/clk-imx7d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -797,7 +797,7 @@ static void __init imx7d_clocks_init(str
clks[IMX7D_MAIN_AXI_ROOT_CLK] = imx_clk_gate4("main_axi_root_clk", "axi_post_div", base + 0x4040, 0);
clks[IMX7D_DISP_AXI_ROOT_CLK] = imx_clk_gate4("disp_axi_root_clk", "disp_axi_post_div", base + 0x4050, 0);
clks[IMX7D_ENET_AXI_ROOT_CLK] = imx_clk_gate4("enet_axi_root_clk", "enet_axi_post_div", base + 0x4060, 0);
- clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "axi_post_div", base + 0x4110, 0);
+ clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "main_axi_root_clk", base + 0x4110, 0);
clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk", "ahb_root_clk", base + 0x4120, 0);
clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk", "dram_post_div", base + 0x4130, 0);
clks[IMX7D_DRAM_PHYM_ROOT_CLK] = imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130, 0);
Patches currently in stable-queue which might be from adriana.reus(a)nxp.com are
queue-4.14/clk-imx-imx7d-fix-parent-clock-for-ocram_clk.patch
This is a note to let you know that I've just added the patch titled
clk: hi6220: mark clock cs_atb_syspll as critical
to the 4.14-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:
clk-hi6220-mark-clock-cs_atb_syspll-as-critical.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Leo Yan <leo.yan(a)linaro.org>
Date: Fri, 1 Sep 2017 08:47:14 +0800
Subject: clk: hi6220: mark clock cs_atb_syspll as critical
From: Leo Yan <leo.yan(a)linaro.org>
[ Upstream commit d2a3671ebe6479483a12f94fcca63c058d95ad64 ]
Clock cs_atb_syspll is pll used for coresight trace bus; when clock
cs_atb_syspll is disabled and operates its child clock node cs_atb
results in system hang. So mark clock cs_atb_syspll as critical to
keep it enabled.
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Zhangfei Gao <zhangfei.gao(a)linaro.org>
Cc: Haojian Zhuang <haojian.zhuang(a)linaro.org>
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
Signed-off-by: Michael Turquette <mturquette(a)baylibre.com>
Link: lkml.kernel.org/r/1504226835-2115-2-git-send-email-leo.yan@linaro.org
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/hisilicon/clk-hi6220.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/hisilicon/clk-hi6220.c
+++ b/drivers/clk/hisilicon/clk-hi6220.c
@@ -145,7 +145,7 @@ static struct hisi_gate_clock hi6220_sep
{ HI6220_BBPPLL_SEL, "bbppll_sel", "pll0_bbp_gate", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 9, 0, },
{ HI6220_MEDIA_PLL_SRC, "media_pll_src", "pll_media_gate", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 10, 0, },
{ HI6220_MMC2_SEL, "mmc2_sel", "mmc2_mux1", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 11, 0, },
- { HI6220_CS_ATB_SYSPLL, "cs_atb_syspll", "syspll", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 12, 0, },
+ { HI6220_CS_ATB_SYSPLL, "cs_atb_syspll", "syspll", CLK_SET_RATE_PARENT|CLK_IS_CRITICAL, 0x270, 12, 0, },
};
static struct hisi_mux_clock hi6220_mux_clks_sys[] __initdata = {
Patches currently in stable-queue which might be from leo.yan(a)linaro.org are
queue-4.14/thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch
queue-4.14/clk-hi6220-mark-clock-cs_atb_syspll-as-critical.patch
This is a note to let you know that I've just added the patch titled
btrfs: undo writable superblocke when sprouting fails
to the 4.14-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:
btrfs-undo-writable-superblocke-when-sprouting-fails.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Anand Jain <anand.jain(a)oracle.com>
Date: Thu, 28 Sep 2017 14:51:09 +0800
Subject: btrfs: undo writable superblocke when sprouting fails
From: Anand Jain <anand.jain(a)oracle.com>
[ Upstream commit 0af2c4bf5a012a40a2f9230458087d7f068339d0 ]
When new device is being added to seed FS, seed FS is marked writable,
but when we fail to bring in the new device, we missed to undo the
writable part. This patch fixes it.
Signed-off-by: Anand Jain <anand.jain(a)oracle.com>
Reviewed-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2501,6 +2501,8 @@ int btrfs_init_new_device(struct btrfs_f
return ret;
error_trans:
+ if (seeding_dev)
+ sb->s_flags |= MS_RDONLY;
btrfs_end_transaction(trans);
rcu_string_free(device->name);
btrfs_sysfs_rm_device_link(fs_info->fs_devices, device);
Patches currently in stable-queue which might be from anand.jain(a)oracle.com are
queue-4.14/btrfs-undo-writable-superblocke-when-sprouting-fails.patch
queue-4.14/btrfs-fix-false-eio-for-missing-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: tests: Fix a memory leak in error handling path in 'run_test()'
to the 4.14-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:
btrfs-tests-fix-a-memory-leak-in-error-handling-path-in-run_test.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 10 Sep 2017 13:19:38 +0200
Subject: btrfs: tests: Fix a memory leak in error handling path in 'run_test()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 9ca2e97fa3c3216200afe35a3b111ec51cc796d2 ]
If 'btrfs_alloc_path()' fails, we must free the resources already
allocated, as done in the other error handling paths in this function.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Reviewed-by: Qu Wenruo <quwenruo.btrfs(a)gmx.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/tests/free-space-tree-tests.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/btrfs/tests/free-space-tree-tests.c
+++ b/fs/btrfs/tests/free-space-tree-tests.c
@@ -500,7 +500,8 @@ static int run_test(test_func_t test_fun
path = btrfs_alloc_path();
if (!path) {
test_msg("Couldn't allocate path\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
ret = add_block_group_free_space(&trans, root->fs_info, cache);
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch
queue-4.14/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch
queue-4.14/btrfs-tests-fix-a-memory-leak-in-error-handling-path-in-run_test.patch
This is a note to let you know that I've just added the patch titled
btrfs: fix false EIO for missing device
to the 4.14-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:
btrfs-fix-false-eio-for-missing-device.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Anand Jain <anand.jain(a)oracle.com>
Date: Sat, 14 Oct 2017 08:34:02 +0800
Subject: btrfs: fix false EIO for missing device
From: Anand Jain <anand.jain(a)oracle.com>
[ Upstream commit 102ed2c5ff932439bbbe74c7bd63e6d5baa9f732 ]
When one of the device is missing, bbio_error() takes care of setting
the error status. And if its only IO that is pending in that stripe, it
fails to check the status of the other IO at %bbio_error before setting
the error %bi_status for the %orig_bio. Fix this by checking if
%bbio->error has exceeded the %bbio->max_errors.
Reproducer as below fdatasync error is seen intermittently.
mount -o degraded /dev/sdc /btrfs
dd status=none if=/dev/zero of=$(mktemp /btrfs/XXX) bs=4096 count=1 conv=fdatasync
dd: fdatasync failed for ‘/btrfs/LSe’: Input/output error
The reason for the intermittences of the problem is because
the following conditions have to be met, which depends on timing:
In btrfs_map_bio()
- the RAID1 the missing device has to be at %dev_nr = 1
In bbio_error()
. before bbio_error() is called the bio of the not-missing
device at %dev_nr = 0 must be completed so that the below
condition is true
if (atomic_dec_and_test(&bbio->stripes_pending)) {
Signed-off-by: Anand Jain <anand.jain(a)oracle.com>
Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -6144,7 +6144,10 @@ static void bbio_error(struct btrfs_bio
btrfs_io_bio(bio)->mirror_num = bbio->mirror_num;
bio->bi_iter.bi_sector = logical >> 9;
- bio->bi_status = BLK_STS_IOERR;
+ if (atomic_read(&bbio->error) > bbio->max_errors)
+ bio->bi_status = BLK_STS_IOERR;
+ else
+ bio->bi_status = BLK_STS_OK;
btrfs_end_bbio(bbio, bio);
}
}
Patches currently in stable-queue which might be from anand.jain(a)oracle.com are
queue-4.14/btrfs-undo-writable-superblocke-when-sprouting-fails.patch
queue-4.14/btrfs-fix-false-eio-for-missing-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: Explicitly handle btrfs_update_root failure
to the 4.14-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:
btrfs-explicitly-handle-btrfs_update_root-failure.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Thu, 28 Sep 2017 10:53:17 +0300
Subject: btrfs: Explicitly handle btrfs_update_root failure
From: Nikolay Borisov <nborisov(a)suse.com>
[ Upstream commit 9417ebc8a676487c6ec8825f92fb28f7dbeb5f4b ]
btrfs_udpate_root can fail and it aborts the transaction, the correct
way to handle an aborted transaction is to explicitly end with
btrfs_end_transaction. Even now the code is correct since
btrfs_commit_transaction would handle an aborted transaction but this is
more of an implementation detail. So let's be explicit in handling
failure in btrfs_update_root.
Furthermore btrfs_commit_transaction can also fail and by ignoring it's
return value we could have left the in-memory copy of the root item in
an inconsistent state. So capture the error value which allows us to
correctly revert the RO/RW flags in case of commit failure.
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/ioctl.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1842,8 +1842,13 @@ static noinline int btrfs_ioctl_subvol_s
ret = btrfs_update_root(trans, fs_info->tree_root,
&root->root_key, &root->root_item);
+ if (ret < 0) {
+ btrfs_end_transaction(trans);
+ goto out_reset;
+ }
+
+ ret = btrfs_commit_transaction(trans);
- btrfs_commit_transaction(trans);
out_reset:
if (ret)
btrfs_set_root_flags(&root->root_item, root_flags);
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-explicitly-handle-btrfs_update_root-failure.patch
queue-4.14/btrfs-undo-writable-superblocke-when-sprouting-fails.patch
This is a note to let you know that I've just added the patch titled
btrfs: avoid null pointer dereference on fs_info when calling btrfs_crit
to the 4.14-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:
btrfs-avoid-null-pointer-dereference-on-fs_info-when-calling-btrfs_crit.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Mon, 11 Sep 2017 16:15:28 +0100
Subject: btrfs: avoid null pointer dereference on fs_info when calling btrfs_crit
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 3993b112dac968612b0b213ed59cb30f50b0015b ]
There are checks on fs_info in __btrfs_panic to avoid dereferencing a
null fs_info, however, there is a call to btrfs_crit that may also
dereference a null fs_info. Fix this by adding a check to see if fs_info
is null and only print the s_id if fs_info is non-null.
Detected by CoverityScan CID#401973 ("Dereference after null check")
Fixes: efe120a067c8 ("Btrfs: convert printk to btrfs_ and fix BTRFS prefix")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -202,7 +202,6 @@ static struct ratelimit_state printk_lim
void btrfs_printk(const struct btrfs_fs_info *fs_info, const char *fmt, ...)
{
- struct super_block *sb = fs_info->sb;
char lvl[PRINTK_MAX_SINGLE_HEADER_LEN + 1] = "\0";
struct va_format vaf;
va_list args;
@@ -228,7 +227,8 @@ void btrfs_printk(const struct btrfs_fs_
vaf.va = &args;
if (__ratelimit(ratelimit))
- printk("%sBTRFS %s (device %s): %pV\n", lvl, type, sb->s_id, &vaf);
+ printk("%sBTRFS %s (device %s): %pV\n", lvl, type,
+ fs_info ? fs_info->sb->s_id : "<unknown>", &vaf);
va_end(args);
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/btrfs-avoid-null-pointer-dereference-on-fs_info-when-calling-btrfs_crit.patch
queue-4.14/ipmi_si-fix-memory-leak-on-new_smi.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_ldisc: Fix another race when closing the tty.
to the 4.14-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:
bluetooth-hci_ldisc-fix-another-race-when-closing-the-tty.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Ronald Tschalär <ronald(a)innovation.ch>
Date: Wed, 25 Oct 2017 22:15:19 -0700
Subject: Bluetooth: hci_ldisc: Fix another race when closing the tty.
From: Ronald Tschalär <ronald(a)innovation.ch>
[ Upstream commit 0338b1b393ec7910898e8f7b25b3bf31a7282e16 ]
The following race condition still existed:
P1 P2
cancel_work_sync()
hci_uart_tx_wakeup()
hci_uart_write_work()
hci_uart_dequeue()
clear_bit(HCI_UART_PROTO_READY)
hci_unregister_dev(hdev)
hci_free_dev(hdev)
hu->proto->close(hu)
kfree(hu)
access to hdev and hu
Cancelling the work after clearing the HCI_UART_PROTO_READY bit avoids
this as any hci_uart_tx_wakeup() issued after the flag is cleared will
detect that and not schedule further work.
Signed-off-by: Ronald Tschalär <ronald(a)innovation.ch>
Reviewed-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_ldisc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -510,13 +510,13 @@ static void hci_uart_tty_close(struct tt
if (hdev)
hci_uart_close(hdev);
- cancel_work_sync(&hu->write_work);
-
if (test_bit(HCI_UART_PROTO_READY, &hu->flags)) {
write_lock_irqsave(&hu->proto_lock, flags);
clear_bit(HCI_UART_PROTO_READY, &hu->flags);
write_unlock_irqrestore(&hu->proto_lock, flags);
+ cancel_work_sync(&hu->write_work);
+
if (hdev) {
if (test_bit(HCI_UART_REGISTERED, &hu->flags))
hci_unregister_dev(hdev);
Patches currently in stable-queue which might be from ronald(a)innovation.ch are
queue-4.14/bluetooth-hci_ldisc-fix-another-race-when-closing-the-tty.patch
This is a note to let you know that I've just added the patch titled
blk-mq-sched: dispatch from scheduler IFF progress is made in ->dispatch
to the 4.14-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:
blk-mq-sched-dispatch-from-scheduler-iff-progress-is-made-in-dispatch.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Ming Lei <ming.lei(a)redhat.com>
Date: Sat, 14 Oct 2017 17:22:25 +0800
Subject: blk-mq-sched: dispatch from scheduler IFF progress is made in ->dispatch
From: Ming Lei <ming.lei(a)redhat.com>
[ Upstream commit 5e3d02bbafad38975099b5848f5ebadedcf7bb7e ]
When the hw queue is busy, we shouldn't take requests from the scheduler
queue any more, otherwise it is difficult to do IO merge.
This patch fixes the awful IO performance on some SCSI devices(lpfc,
qla2xxx, ...) when mq-deadline/kyber is used by not taking requests if
hw queue is busy.
Reviewed-by: Omar Sandoval <osandov(a)fb.com>
Reviewed-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-mq-sched.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -94,7 +94,7 @@ void blk_mq_sched_dispatch_requests(stru
struct request_queue *q = hctx->queue;
struct elevator_queue *e = q->elevator;
const bool has_sched_dispatch = e && e->type->ops.mq.dispatch_request;
- bool did_work = false;
+ bool do_sched_dispatch = true;
LIST_HEAD(rq_list);
/* RCU or SRCU read lock is needed before checking quiesced flag */
@@ -125,18 +125,18 @@ void blk_mq_sched_dispatch_requests(stru
*/
if (!list_empty(&rq_list)) {
blk_mq_sched_mark_restart_hctx(hctx);
- did_work = blk_mq_dispatch_rq_list(q, &rq_list);
+ do_sched_dispatch = blk_mq_dispatch_rq_list(q, &rq_list);
} else if (!has_sched_dispatch) {
blk_mq_flush_busy_ctxs(hctx, &rq_list);
blk_mq_dispatch_rq_list(q, &rq_list);
}
/*
- * We want to dispatch from the scheduler if we had no work left
- * on the dispatch list, OR if we did have work but weren't able
- * to make progress.
+ * We want to dispatch from the scheduler if there was nothing
+ * on the dispatch list or we were able to dispatch from the
+ * dispatch list.
*/
- if (!did_work && has_sched_dispatch) {
+ if (do_sched_dispatch && has_sched_dispatch) {
do {
struct request *rq;
Patches currently in stable-queue which might be from ming.lei(a)redhat.com are
queue-4.14/scsi-core-fix-a-scsi_show_rq-null-pointer-dereference.patch
queue-4.14/blk-mq-sched-dispatch-from-scheduler-iff-progress-is-made-in-dispatch.patch
This is a note to let you know that I've just added the patch titled
bcache: fix wrong cache_misses statistics
to the 4.14-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:
bcache-fix-wrong-cache_misses-statistics.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: "tang.junhui" <tang.junhui(a)zte.com.cn>
Date: Mon, 30 Oct 2017 14:46:34 -0700
Subject: bcache: fix wrong cache_misses statistics
From: "tang.junhui" <tang.junhui(a)zte.com.cn>
[ Upstream commit c157313791a999646901b3e3c6888514ebc36d62 ]
Currently, Cache missed IOs are identified by s->cache_miss, but actually,
there are many situations that missed IOs are not assigned a value for
s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO
(s->iop.bypass = 1), or the cache_bio allocate failed. In these situations,
it will go to out_put or out_submit, and s->cache_miss is null, which leads
bch_mark_cache_accounting() to treat this IO as a hit IO.
[ML: applied by 3-way merge]
Signed-off-by: tang.junhui <tang.junhui(a)zte.com.cn>
Reviewed-by: Michael Lyle <mlyle(a)lyle.org>
Reviewed-by: Coly Li <colyli(a)suse.de>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/request.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -463,6 +463,7 @@ struct search {
unsigned recoverable:1;
unsigned write:1;
unsigned read_dirty_data:1;
+ unsigned cache_missed:1;
unsigned long start_time;
@@ -649,6 +650,7 @@ static inline struct search *search_allo
s->orig_bio = bio;
s->cache_miss = NULL;
+ s->cache_missed = 0;
s->d = d;
s->recoverable = 1;
s->write = op_is_write(bio_op(bio));
@@ -767,7 +769,7 @@ static void cached_dev_read_done_bh(stru
struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
bch_mark_cache_accounting(s->iop.c, s->d,
- !s->cache_miss, s->iop.bypass);
+ !s->cache_missed, s->iop.bypass);
trace_bcache_read(s->orig_bio, !s->cache_miss, s->iop.bypass);
if (s->iop.status)
@@ -786,6 +788,8 @@ static int cached_dev_cache_miss(struct
struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
struct bio *miss, *cache_bio;
+ s->cache_missed = 1;
+
if (s->cache_miss || s->iop.bypass) {
miss = bio_next_split(bio, sectors, GFP_NOIO, s->d->bio_split);
ret = miss == bio ? MAP_DONE : MAP_CONTINUE;
Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are
queue-4.14/bcache-fix-wrong-cache_misses-statistics.patch
This is a note to let you know that I've just added the patch titled
bcache: explicitly destroy mutex while exiting
to the 4.14-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:
bcache-explicitly-destroy-mutex-while-exiting.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Liang Chen <liangchen.linux(a)gmail.com>
Date: Mon, 30 Oct 2017 14:46:35 -0700
Subject: bcache: explicitly destroy mutex while exiting
From: Liang Chen <liangchen.linux(a)gmail.com>
[ Upstream commit 330a4db89d39a6b43f36da16824eaa7a7509d34d ]
mutex_destroy does nothing most of time, but it's better to call
it to make the code future proof and it also has some meaning
for like mutex debug.
As Coly pointed out in a previous review, bcache_exit() may not be
able to handle all the references properly if userspace registers
cache and backing devices right before bch_debug_init runs and
bch_debug_init failes later. So not exposing userspace interface
until everything is ready to avoid that issue.
Signed-off-by: Liang Chen <liangchen.linux(a)gmail.com>
Reviewed-by: Michael Lyle <mlyle(a)lyle.org>
Reviewed-by: Coly Li <colyli(a)suse.de>
Reviewed-by: Eric Wheeler <bcache(a)linux.ewheeler.net>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/super.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -2085,6 +2085,7 @@ static void bcache_exit(void)
if (bcache_major)
unregister_blkdev(bcache_major, "bcache");
unregister_reboot_notifier(&reboot);
+ mutex_destroy(&bch_register_lock);
}
static int __init bcache_init(void)
@@ -2103,14 +2104,15 @@ static int __init bcache_init(void)
bcache_major = register_blkdev(0, "bcache");
if (bcache_major < 0) {
unregister_reboot_notifier(&reboot);
+ mutex_destroy(&bch_register_lock);
return bcache_major;
}
if (!(bcache_wq = alloc_workqueue("bcache", WQ_MEM_RECLAIM, 0)) ||
!(bcache_kobj = kobject_create_and_add("bcache", fs_kobj)) ||
- sysfs_create_files(bcache_kobj, files) ||
bch_request_init() ||
- bch_debug_init(bcache_kobj))
+ bch_debug_init(bcache_kobj) ||
+ sysfs_create_files(bcache_kobj, files))
goto err;
return 0;
Patches currently in stable-queue which might be from liangchen.linux(a)gmail.com are
queue-4.14/bcache-explicitly-destroy-mutex-while-exiting.patch
PATCH 1/2 is to fix switch upstream/downstream port error report.
PATCH 2/2 is to make AER device configuration more reasonable.
Delete the upstream/downstream port AER configuraion in PATCH 2/2,
but if firmware does not enable upstream/downstream port error reporting,
it seems current no place to enable them, so PATCH 2/2 need more
suggestion. Please see the commit log for more information.
Changes from v1:
- Rebase on v4.15-rc2.
- Modify the change log.
- Add PATCH 2/2.
Dongdong Liu (2):
PCI/portdrv: Fix switch devctrl error report enable
PCI/AER: Fix AER device configuration
drivers/pci/pcie/aer/aerdrv.c | 49 ++++-------------------------------------
drivers/pci/pcie/portdrv_core.c | 4 +++-
2 files changed, 7 insertions(+), 46 deletions(-)
--
1.9.1
This is a note to let you know that I've just added the patch titled
badblocks: fix wrong return value in badblocks_set if badblocks are disabled
to the 4.14-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:
badblocks-fix-wrong-return-value-in-badblocks_set-if-badblocks-are-disabled.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Fri, 3 Nov 2017 11:24:44 -0600
Subject: badblocks: fix wrong return value in badblocks_set if badblocks are disabled
From: Liu Bo <bo.li.liu(a)oracle.com>
[ Upstream commit 39b4954c0a1556f8f7f1fdcf59a227117fcd8a0b ]
MD's rdev_set_badblocks() expects that badblocks_set() returns 1 if
badblocks are disabled, otherwise, rdev_set_badblocks() will record
superblock changes and return success in that case and md will fail to
report an IO error which it should.
This bug has existed since badblocks were introduced in commit
9e0e252a048b ("badblocks: Add core badblock management code").
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Acked-by: Guoqing Jiang <gqjiang(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/badblocks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/block/badblocks.c
+++ b/block/badblocks.c
@@ -178,7 +178,7 @@ int badblocks_set(struct badblocks *bb,
if (bb->shift < 0)
/* badblocks are disabled */
- return 0;
+ return 1;
if (bb->shift) {
/* round the start down, and the end up */
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.14/badblocks-fix-wrong-return-value-in-badblocks_set-if-badblocks-are-disabled.patch
queue-4.14/btrfs-fix-false-eio-for-missing-device.patch
This is a note to let you know that I've just added the patch titled
ath9k: fix tx99 potential info leak
to the 4.14-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:
ath9k-fix-tx99-potential-info-leak.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Miaoqing Pan <miaoqing(a)codeaurora.org>
Date: Wed, 27 Sep 2017 09:13:34 +0800
Subject: ath9k: fix tx99 potential info leak
From: Miaoqing Pan <miaoqing(a)codeaurora.org>
[ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ]
When the user sets count to zero the string buffer would remain
completely uninitialized which causes the kernel to parse its
own stack data, potentially leading to an info leak. In addition
to that, the string might be not terminated properly when the
user data does not contain a 0-terminator.
Signed-off-by: Miaoqing Pan <miaoqing(a)codeaurora.org>
Reviewed-by: Christoph Böhmwalder <christoph(a)boehmwalder.at>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/tx99.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -179,6 +179,9 @@ static ssize_t write_file_tx99(struct fi
ssize_t len;
int r;
+ if (count < 1)
+ return -EINVAL;
+
if (sc->cur_chan->nvifs > 1)
return -EOPNOTSUPP;
@@ -186,6 +189,8 @@ static ssize_t write_file_tx99(struct fi
if (copy_from_user(buf, user_buf, len))
return -EFAULT;
+ buf[len] = '\0';
+
if (strtobool(buf, &start))
return -EINVAL;
Patches currently in stable-queue which might be from miaoqing(a)codeaurora.org are
queue-4.14/ath9k-fix-tx99-potential-info-leak.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix core PCI suspend when WoWLAN is supported but disabled
to the 4.14-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:
ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Brian Norris <briannorris(a)chromium.org>
Date: Wed, 4 Oct 2017 12:22:55 +0300
Subject: ath10k: fix core PCI suspend when WoWLAN is supported but disabled
From: Brian Norris <briannorris(a)chromium.org>
[ Upstream commit 96378bd2c6cda5f04d0f6da2cd35d4670a982c38 ]
For devices where the FW supports WoWLAN but user-space has not
configured it, we don't do any PCI-specific suspend/resume operations,
because mac80211 doesn't call drv_suspend() when !wowlan. This has
particularly bad effects for some platforms, because we don't stop the
power-save timer, and if this timer goes off after the PCI controller
has suspended the link, Bad Things will happen.
Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
got some of this right, in that it understood there was a problem on
non-WoWLAN firmware. But it forgot the $subject case.
Fix this by moving all the PCI driver suspend/resume logic exclusively
into the driver PM hooks. This shouldn't affect WoWLAN support much
(this just gets executed later on).
I would just as well kill the entirety of ath10k_hif_suspend(), as it's
not even implemented on the USB or SDIO drivers. I expect that we don't
need the callback, except to return "supported" (i.e., 0) or "not
supported" (i.e., -EOPNOTSUPP).
Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
Cc: Ryan Hsu <ryanhsu(a)qti.qualcomm.com>
Cc: Kalle Valo <kvalo(a)qca.qualcomm.com>
Cc: Michal Kazior <michal.kazior(a)tieto.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/pci.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2581,6 +2581,12 @@ void ath10k_pci_hif_power_down(struct at
static int ath10k_pci_hif_suspend(struct ath10k *ar)
{
+ /* Nothing to do; the important stuff is in the driver suspend. */
+ return 0;
+}
+
+static int ath10k_pci_suspend(struct ath10k *ar)
+{
/* The grace timer can still be counting down and ar->ps_awake be true.
* It is known that the device may be asleep after resuming regardless
* of the SoC powersave state before suspending. Hence make sure the
@@ -2593,6 +2599,12 @@ static int ath10k_pci_hif_suspend(struct
static int ath10k_pci_hif_resume(struct ath10k *ar)
{
+ /* Nothing to do; the important stuff is in the driver resume. */
+ return 0;
+}
+
+static int ath10k_pci_resume(struct ath10k *ar)
+{
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
struct pci_dev *pdev = ar_pci->pdev;
u32 val;
@@ -3401,11 +3413,7 @@ static __maybe_unused int ath10k_pci_pm_
struct ath10k *ar = dev_get_drvdata(dev);
int ret;
- if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
- ar->running_fw->fw_file.fw_features))
- return 0;
-
- ret = ath10k_hif_suspend(ar);
+ ret = ath10k_pci_suspend(ar);
if (ret)
ath10k_warn(ar, "failed to suspend hif: %d\n", ret);
@@ -3417,11 +3425,7 @@ static __maybe_unused int ath10k_pci_pm_
struct ath10k *ar = dev_get_drvdata(dev);
int ret;
- if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
- ar->running_fw->fw_file.fw_features))
- return 0;
-
- ret = ath10k_hif_resume(ar);
+ ret = ath10k_pci_resume(ar);
if (ret)
ath10k_warn(ar, "failed to resume hif: %d\n", ret);
Patches currently in stable-queue which might be from briannorris(a)chromium.org are
queue-4.14/ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.patch
queue-4.14/ath10k-fix-build-errors-with-config_pm.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix build errors with !CONFIG_PM
to the 4.14-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:
ath10k-fix-build-errors-with-config_pm.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Brian Norris <briannorris(a)chromium.org>
Date: Thu, 19 Oct 2017 11:45:19 -0700
Subject: ath10k: fix build errors with !CONFIG_PM
From: Brian Norris <briannorris(a)chromium.org>
[ Upstream commit 20665a9076d48e9abd9a2db13d307f58f7ef6647 ]
Build errors have been reported with CONFIG_PM=n:
drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit
declaration of function 'ath10k_pci_suspend'
[-Werror=implicit-function-declaration]
drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit
declaration of function 'ath10k_pci_resume'
[-Werror=implicit-function-declaration]
These are caused by the combination of the following two commits:
6af1de2e4ec4 ("ath10k: mark PM functions as __maybe_unused")
96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but
disabled")
Both build fine on their own.
But now that ath10k_pci_pm_{suspend,resume}() is compiled
unconditionally, we should also compile ath10k_pci_{suspend,resume}()
unconditionally.
And drop the #ifdef around ath10k_pci_hif_{suspend,resume}() too; they
are trivial (empty), so we're not saving much space by compiling them
out. And the alternatives would be to sprinkle more __maybe_unused, or
spread the #ifdef's further.
Build tested with the following combinations:
CONFIG_PM=y && CONFIG_PM_SLEEP=y
CONFIG_PM=y && CONFIG_PM_SLEEP=n
CONFIG_PM=n
Fixes: 96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but disabled")
Fixes: 096ad2a15fd8 ("Merge branch 'ath-next'")
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/pci.c | 5 -----
1 file changed, 5 deletions(-)
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2577,8 +2577,6 @@ void ath10k_pci_hif_power_down(struct at
*/
}
-#ifdef CONFIG_PM
-
static int ath10k_pci_hif_suspend(struct ath10k *ar)
{
/* Nothing to do; the important stuff is in the driver suspend. */
@@ -2627,7 +2625,6 @@ static int ath10k_pci_resume(struct ath1
return ret;
}
-#endif
static bool ath10k_pci_validate_cal(void *data, size_t size)
{
@@ -2782,10 +2779,8 @@ static const struct ath10k_hif_ops ath10
.power_down = ath10k_pci_hif_power_down,
.read32 = ath10k_pci_read32,
.write32 = ath10k_pci_write32,
-#ifdef CONFIG_PM
.suspend = ath10k_pci_hif_suspend,
.resume = ath10k_pci_hif_resume,
-#endif
.fetch_cal_eeprom = ath10k_pci_hif_fetch_cal_eeprom,
};
Patches currently in stable-queue which might be from briannorris(a)chromium.org are
queue-4.14/ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.patch
queue-4.14/ath10k-fix-build-errors-with-config_pm.patch
This is a note to let you know that I've just added the patch titled
ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod
to the 4.14-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:
asoc-rsnd-rsnd_ssi_run_mods-needs-to-care-ssi_parent_mod.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Wed, 1 Nov 2017 07:16:58 +0000
Subject: ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
[ Upstream commit 21781e87881f9c420871b1d1f3f29d4cd7bffb10 ]
SSI parent mod might be NULL. ssi_parent_mod() needs to care
about it. Otherwise, it uses negative shift.
This patch fixes it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sh/rcar/ssi.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -198,10 +198,15 @@ static u32 rsnd_ssi_run_mods(struct rsnd
{
struct rsnd_mod *ssi_mod = rsnd_io_to_mod_ssi(io);
struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
+ u32 mods;
- return rsnd_ssi_multi_slaves_runtime(io) |
- 1 << rsnd_mod_id(ssi_mod) |
- 1 << rsnd_mod_id(ssi_parent_mod);
+ mods = rsnd_ssi_multi_slaves_runtime(io) |
+ 1 << rsnd_mod_id(ssi_mod);
+
+ if (ssi_parent_mod)
+ mods |= 1 << rsnd_mod_id(ssi_parent_mod);
+
+ return mods;
}
u32 rsnd_ssi_multi_slaves_runtime(struct rsnd_dai_stream *io)
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.14/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch
queue-4.14/asoc-rsnd-rsnd_ssi_run_mods-needs-to-care-ssi_parent_mod.patch