- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "dmaengine: Fix array index out of bounds warning in __get_unmap_pool()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: Fix array index out of bounds warning in __get_unmap_pool() to the 4.9-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-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Matthias Kaehlcke <mka(a)chromium.org> Date: Mon, 13 Mar 2017 14:30:29 -0700 Subject: dmaengine: Fix array index out of bounds warning in __get_unmap_pool() From: Matthias Kaehlcke <mka(a)chromium.org> [ Upstream commit 23f963e91fd81f44f6b316b1c24db563354c6be8 ] This fixes the following warning when building with clang and CONFIG_DMA_ENGINE_RAID=n : drivers/dma/dmaengine.c:1102:11: error: array index 2 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] return &unmap_pool[2]; ^ ~ drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here static struct dmaengine_unmap_pool unmap_pool[] = { ^ drivers/dma/dmaengine.c:1104:11: error: array index 3 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] return &unmap_pool[3]; ^ ~ drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here static struct dmaengine_unmap_pool unmap_pool[] = { Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org> Reviewed-by: Dan Williams <dan.j.williams(a)intel.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/dmaengine.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -1107,12 +1107,14 @@ static struct dmaengine_unmap_pool *__ge switch (order) { case 0 ... 1: return &unmap_pool[0]; +#if IS_ENABLED(CONFIG_DMA_ENGINE_RAID) case 2 ... 4: return &unmap_pool[1]; case 5 ... 7: return &unmap_pool[2]; case 8: return &unmap_pool[3]; +#endif default: BUG(); return NULL; Patches currently in stable-queue which might be from mka(a)chromium.org are queue-4.9/bluetooth-btusb-driver-to-enable-the-usb-wakeup-feature.patch queue-4.9/dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: tcrypt - fix buffer lengths in test_aead_speed()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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 @@ -342,7 +342,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)); @@ -350,7 +350,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.9/crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: tegra: Fix cclk_lp divisor register" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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 @@ -963,7 +963,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.9/clk-tegra-fix-cclk_lp-divisor-register.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: mediatek: add the option for determining PLL source clock" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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 @@ -185,6 +185,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 @@ -302,7 +302,10 @@ static struct clk *mtk_clk_register_pll( init.name = data->name; 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.9/clk-mediatek-add-the-option-for-determining-pll-source-clock.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU to the 4.9-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-imx6-refine-hdmi_isfr-s-parent-to-make-hdmi-work-on-i.mx6-socs-w-o-vpu.patch and it can be found in the queue-4.9 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 14:12:35 CET 2017 From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> Date: Tue, 1 Aug 2017 12:40:07 +0200 Subject: clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> [ Upstream commit c68ee58d9ee7b856ac722f18f4f26579c8fbd2b4 ] On i.MX6 SoCs without VPU (in my case MCIMX6D4AVT10AC), the hdmi driver fails to probe: [ 2.540030] dwhdmi-imx 120000.hdmi: Unsupported HDMI controller (0000:00:00) [ 2.548199] imx-drm display-subsystem: failed to bind 120000.hdmi (ops dw_hdmi_imx_ops): -19 [ 2.557403] imx-drm display-subsystem: master bind failed: -19 That's because hdmi_isfr's parent, video_27m, is not correctly ungated. As explained in commit 5ccc248cc537 ("ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate"), video_27m is gated by CCM_CCGR3[CG8]. On i.MX6 SoCs with VPU, the hdmi is working thanks to the CCM_CMEOR[mod_en_ov_vpu] bit which makes the video_27m ungated whatever is in CCM_CCGR3[CG8]. The issue can be reproduced by setting CCMEOR[mod_en_ov_vpu] to 0. Make the HDMI work in every case by setting hdmi_isfr's parent to mipi_core_cfg. Signed-off-by: SÃ©bastien Szymanski <sebastien.szymanski(a)armadeus.com> Reviewed-by: Fabio Estevam <fabio.estevam(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-imx6q.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/imx/clk-imx6q.c +++ b/drivers/clk/imx/clk-imx6q.c @@ -487,7 +487,7 @@ static void __init imx6q_clocks_init(str clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu2d_core_podf", base + 0x6c, 24); clk[IMX6QDL_CLK_GPU3D_CORE] = imx_clk_gate2("gpu3d_core", "gpu3d_core_podf", base + 0x6c, 26); clk[IMX6QDL_CLK_HDMI_IAHB] = imx_clk_gate2("hdmi_iahb", "ahb", base + 0x70, 0); - clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "video_27m", base + 0x70, 4); + clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "mipi_core_cfg", base + 0x70, 4); clk[IMX6QDL_CLK_I2C1] = imx_clk_gate2("i2c1", "ipg_per", base + 0x70, 6); clk[IMX6QDL_CLK_I2C2] = imx_clk_gate2("i2c2", "ipg_per", base + 0x70, 8); clk[IMX6QDL_CLK_I2C3] = imx_clk_gate2("i2c3", "ipg_per", base + 0x70, 10); Patches currently in stable-queue which might be from sebastien.szymanski(a)armadeus.com are queue-4.9/clk-imx6-refine-hdmi_isfr-s-parent-to-make-hdmi-work-on-i.mx6-socs-w-o-vpu.patch queue-4.9/hid-cp2112-fix-broken-gpio_direction_input-callback.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: hi6220: mark clock cs_atb_syspll as critical" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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 @@ -144,7 +144,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.9/thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch queue-4.9/clk-hi6220-mark-clock-cs_atb_syspll-as-critical.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: tests: Fix a memory leak in error handling path in 'run_test()'" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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 @@ -501,7 +501,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.9/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch queue-4.9/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch queue-4.9/btrfs-tests-fix-a-memory-leak-in-error-handling-path-in-run_test.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: add missing memset while reading compressed inline extents" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: add missing memset while reading compressed inline extents to the 4.9-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-add-missing-memset-while-reading-compressed-inline-extents.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Date: Fri, 10 Mar 2017 16:45:44 -0500 Subject: btrfs: add missing memset while reading compressed inline extents From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> [ Upstream commit e1699d2d7bf6e6cce3e1baff19f9dd4595a58664 ] This is a story about 4 distinct (and very old) btrfs bugs. Commit c8b978188c ("Btrfs: Add zlib compression support") added three data corruption bugs for inline extents (bugs #1-3). Commit 93c82d5750 ("Btrfs: zero page past end of inline file items") fixed bug #1: uncompressed inline extents followed by a hole and more extents could get non-zero data in the hole as they were read. The fix was to add a memset in btrfs_get_extent to zero out the hole. Commit 166ae5a418 ("btrfs: fix inline compressed read err corruption") fixed bug #2: compressed inline extents which contained non-zero bytes might be replaced with zero bytes in some cases. This patch removed an unhelpful memset from uncompress_inline, but the case where memset is required was missed. There is also a memset in the decompression code, but this only covers decompressed data that is shorter than the ram_bytes from the extent ref record. This memset doesn't cover the region between the end of the decompressed data and the end of the page. It has also moved around a few times over the years, so there's no single patch to refer to. This patch fixes bug #3: compressed inline extents followed by a hole and more extents could get non-zero data in the hole as they were read (i.e. bug #3 is the same as bug #1, but s/uncompressed/compressed/). The fix is the same: zero out the hole in the compressed case too, by putting a memset back in uncompress_inline, but this time with correct parameters. The last and oldest bug, bug #0, is the cause of the offending inline extent/hole/extent pattern. Bug #0 is a subtle and mostly-harmless quirk of behavior somewhere in the btrfs write code. In a few special cases, an inline extent and hole are allowed to persist where they normally would be combined with later extents in the file. A fast reproducer for bug #0 is presented below. A few offending extents are also created in the wild during large rsync transfers with the -S flag. A Linux kernel build (git checkout; make allyesconfig; make -j8) will produce a handful of offending files as well. Once an offending file is created, it can present different content to userspace each time it is read. Bug #0 is at least 4 and possibly 8 years old. I verified every vX.Y kernel back to v3.5 has this behavior. There are fossil records of this bug's effects in commits all the way back to v2.6.32. I have no reason to believe bug #0 wasn't present at the beginning of btrfs compression support in v2.6.29, but I can't easily test kernels that old to be sure. It is not clear whether bug #0 is worth fixing. A fix would likely require injecting extra reads into currently write-only paths, and most of the exceptional cases caused by bug #0 are already handled now. Whether we like them or not, bug #0's inline extents followed by holes are part of the btrfs de-facto disk format now, and we need to be able to read them without data corruption or an infoleak. So enough about bug #0, let's get back to bug #3 (this patch). An example of on-disk structure leading to data corruption found in the wild: item 61 key (606890 INODE_ITEM 0) itemoff 9662 itemsize 160 inode generation 50 transid 50 size 47424 nbytes 49141 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 flags 0x0(none) item 62 key (606890 INODE_REF 603050) itemoff 9642 itemsize 20 inode ref index 3 namelen 10 name: DB_File.so item 63 key (606890 EXTENT_DATA 0) itemoff 8280 itemsize 1362 inline extent data size 1341 ram 4085 compress(zlib) item 64 key (606890 EXTENT_DATA 4096) itemoff 8227 itemsize 53 extent data disk byte 5367308288 nr 20480 extent data offset 0 nr 45056 ram 45056 extent compression(zlib) Different data appears in userspace during each read of the 11 bytes between 4085 and 4096. The extent in item 63 is not long enough to fill the first page of the file, so a memset is required to fill the space between item 63 (ending at 4085) and item 64 (beginning at 4096) with zero. Here is a reproducer from Liu Bo, which demonstrates another method of creating the same inline extent and hole pattern: Using 'page_poison=on' kernel command line (or enable CONFIG_PAGE_POISONING) run the following: # touch foo # chattr +c foo # xfs_io -f -c "pwrite -W 0 1000" foo # xfs_io -f -c "falloc 4 8188" foo # od -x foo # echo 3 >/proc/sys/vm/drop_caches # od -x foo This produce the following on my box: Correct output: file contains 1000 data bytes followed by zeros: 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0001740 cdcd cdcd cdcd cdcd 0000 0000 0000 0000 0001760 0000 0000 0000 0000 0000 0000 0000 0000 * 0020000 Actual output: the data after the first 1000 bytes will be different each run: 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0001740 cdcd cdcd cdcd cdcd 6c63 7400 635f 006d 0001760 5f74 6f43 7400 435f 0053 5f74 7363 7400 0002000 435f 0056 5f74 6164 7400 645f 0062 5f74 (...) Signed-off-by: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Chris Mason <clm(a)fb.com> Signed-off-by: Chris Mason <clm(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -6812,6 +6812,20 @@ static noinline int uncompress_inline(st max_size = min_t(unsigned long, PAGE_SIZE, max_size); ret = btrfs_decompress(compress_type, tmp, page, extent_offset, inline_size, max_size); + + /* + * decompression code contains a memset to fill in any space between the end + * of the uncompressed data and the end of max_size in case the decompressed + * data ends up shorter than ram_bytes. That doesn't cover the hole between + * the end of an inline extent and the beginning of the next block, so we + * cover that region here. + */ + + if (max_size + pg_offset < PAGE_SIZE) { + char *map = kmap(page); + memset(map + pg_offset + max_size, 0, PAGE_SIZE - max_size - pg_offset); + kunmap(page); + } kfree(tmp); return ret; } Patches currently in stable-queue which might be from ce3g8jdj(a)umail.furryterror.org are queue-4.9/btrfs-add-missing-memset-while-reading-compressed-inline-extents.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "bnxt_en: Ignore 0 value in autoneg supported speed from firmware." has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bnxt_en: Ignore 0 value in autoneg supported speed from firmware. to the 4.9-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-ignore-0-value-in-autoneg-supported-speed-from-firmware.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Michael Chan <michael.chan(a)broadcom.com> Date: Wed, 8 Mar 2017 18:44:35 -0500 Subject: bnxt_en: Ignore 0 value in autoneg supported speed from firmware. From: Michael Chan <michael.chan(a)broadcom.com> [ Upstream commit 520ad89a54edea84496695d528f73ddcf4a52ea4 ] In some situations, the firmware will return 0 for autoneg supported speed. This may happen if the firmware detects no SFP module, for example. The driver should ignore this so that we don't end up with an invalid autoneg setting with nothing advertised. When SFP module is inserted, we'll get the updated settings from firmware at that time. 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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -5132,8 +5132,9 @@ static int bnxt_hwrm_phy_qcaps(struct bn bp->lpi_tmr_hi = le32_to_cpu(resp->valid_tx_lpi_timer_high) & PORT_PHY_QCAPS_RESP_TX_LPI_TIMER_HIGH_MASK; } - link_info->support_auto_speeds = - le16_to_cpu(resp->supported_speeds_auto_mode); + if (resp->supported_speeds_auto_mode) + link_info->support_auto_speeds = + le16_to_cpu(resp->supported_speeds_auto_mode); hwrm_phy_qcaps_exit: mutex_unlock(&bp->hwrm_cmd_lock); Patches currently in stable-queue which might be from michael.chan(a)broadcom.com are queue-4.9/bnxt_en-ignore-0-value-in-autoneg-supported-speed-from-firmware.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "blk-mq: Fix tagset reinit in the presence of cpu hot-unplug" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-mq: Fix tagset reinit in the presence of cpu hot-unplug to the 4.9-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-fix-tagset-reinit-in-the-presence-of-cpu-hot-unplug.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Sagi Grimberg <sagi(a)grimberg.me> Date: Mon, 13 Mar 2017 16:10:11 +0200 Subject: blk-mq: Fix tagset reinit in the presence of cpu hot-unplug From: Sagi Grimberg <sagi(a)grimberg.me> [ Upstream commit 0067d4b020ea07a58540acb2c5fcd3364bf326e0 ] In case cpu was unplugged, we need to make sure not to assume that the tags for that cpu are still allocated. so check for null tags when reinitializing a tagset. Reported-by: Yi Zhang <yizhan(a)redhat.com> Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Jens Axboe <axboe(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq-tag.c | 3 +++ 1 file changed, 3 insertions(+) --- a/block/blk-mq-tag.c +++ b/block/blk-mq-tag.c @@ -311,6 +311,9 @@ int blk_mq_reinit_tagset(struct blk_mq_t for (i = 0; i < set->nr_hw_queues; i++) { struct blk_mq_tags *tags = set->tags[i]; + if (!tags) + continue; + for (j = 0; j < tags->nr_tags; j++) { if (!tags->rqs[j]) continue; Patches currently in stable-queue which might be from sagi(a)grimberg.me are queue-4.9/blk-mq-fix-tagset-reinit-in-the-presence-of-cpu-hot-unplug.patch queue-4.9/nvmet-confirm-sq-percpu-has-scheduled-and-switched-to-atomic.patch queue-4.9/nvme-use-kref_get_unless_zero-in-nvme_find_get_ns.patch queue-4.9/nvme-loop-fix-a-possible-use-after-free-when-destroying-the-admin-queue.patch queue-4.9/nvmet-rdma-fix-a-possible-uninitialized-variable-dereference.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "bcache: fix wrong cache_misses statistics" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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 @@ -468,6 +468,7 @@ struct search { unsigned recoverable:1; unsigned write:1; unsigned read_dirty_data:1; + unsigned cache_missed:1; unsigned long start_time; @@ -653,6 +654,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)); @@ -771,7 +773,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.error) @@ -790,6 +792,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.9/bcache-fix-wrong-cache_misses-statistics.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "bcache: explicitly destroy mutex while exiting" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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 @@ -2091,6 +2091,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) @@ -2109,14 +2110,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.9/bcache-explicitly-destroy-mutex-while-exiting.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "badblocks: fix wrong return value in badblocks_set if badblocks are disabled" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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.9/badblocks-fix-wrong-return-value-in-badblocks_set-if-badblocks-are-disabled.patch queue-4.9/btrfs-add-missing-memset-while-reading-compressed-inline-extents.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "ath9k: fix tx99 potential info leak" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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.9/ath9k-fix-tx99-potential-info-leak.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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.9-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.9 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 14:12:35 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 @@ -172,10 +172,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.9/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch queue-4.9/asoc-rcar-clear-de-bit-only-in-pdmachcr-when-it-stops.patch queue-4.9/asoc-rsnd-rsnd_ssi_run_mods-needs-to-care-ssi_parent_mod.patch queue-4.9/asoc-rsnd-fix-sound-route-path-when-using-src6-src9.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: rsnd: fix sound route path when using SRC6/SRC9" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: rsnd: fix sound route path when using SRC6/SRC9 to the 4.9-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-fix-sound-route-path-when-using-src6-src9.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> Date: Wed, 1 Mar 2017 03:51:00 +0000 Subject: ASoC: rsnd: fix sound route path when using SRC6/SRC9 From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> [ Upstream commit a1c2ff53726907aff5feb37e4cfd45c1ff626431 ] This patch fixes the problem that the missing value of the route path setting table and incorrect values are set in the CMD_ROUTE_SELECT register. Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> [Kuninori: shared data on MIX and non-MIX case] 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/cmd.c | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) --- a/sound/soc/sh/rcar/cmd.c +++ b/sound/soc/sh/rcar/cmd.c @@ -31,23 +31,24 @@ static int rsnd_cmd_init(struct rsnd_mod struct rsnd_mod *mix = rsnd_io_to_mod_mix(io); struct device *dev = rsnd_priv_to_dev(priv); u32 data; + u32 path[] = { + [1] = 1 << 0, + [5] = 1 << 8, + [6] = 1 << 12, + [9] = 1 << 15, + }; if (!mix && !dvc) return 0; + if (ARRAY_SIZE(path) < rsnd_mod_id(mod) + 1) + return -ENXIO; + if (mix) { struct rsnd_dai *rdai; struct rsnd_mod *src; struct rsnd_dai_stream *tio; int i; - u32 path[] = { - [0] = 0, - [1] = 1 << 0, - [2] = 0, - [3] = 0, - [4] = 0, - [5] = 1 << 8 - }; /* * it is assuming that integrater is well understanding about @@ -70,16 +71,19 @@ static int rsnd_cmd_init(struct rsnd_mod } else { struct rsnd_mod *src = rsnd_io_to_mod_src(io); - u32 path[] = { - [0] = 0x30000, - [1] = 0x30001, - [2] = 0x40000, - [3] = 0x10000, - [4] = 0x20000, - [5] = 0x40100 + u8 cmd_case[] = { + [0] = 0x3, + [1] = 0x3, + [2] = 0x4, + [3] = 0x1, + [4] = 0x2, + [5] = 0x4, + [6] = 0x1, + [9] = 0x2, }; - data = path[rsnd_mod_id(src)]; + data = path[rsnd_mod_id(src)] | + cmd_case[rsnd_mod_id(src)] << 16; } dev_dbg(dev, "ctu/mix path = 0x%08x", data); Patches currently in stable-queue which might be from hiroyuki.yokoyama.vx(a)renesas.com are queue-4.9/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch queue-4.9/asoc-rcar-clear-de-bit-only-in-pdmachcr-when-it-stops.patch queue-4.9/asoc-rsnd-fix-sound-route-path-when-using-src6-src9.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: rcar: clear DE bit only in PDMACHCR when it stops" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: rcar: clear DE bit only in PDMACHCR when it stops to the 4.9-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-rcar-clear-de-bit-only-in-pdmachcr-when-it-stops.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Date: Tue, 14 Mar 2017 09:34:49 +0900 Subject: ASoC: rcar: clear DE bit only in PDMACHCR when it stops From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> [ Upstream commit 62a10498afb27370ec6018e9d802b74850fd8d9a ] R-Car datasheet indicates "Clear DE in PDMACHCR" for transfer stop, but current code clears all bits in PDMACHCR. Because of this, DE bit might never been cleared, and it causes CMD overflow. This patch fixes this issue. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(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/dma.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) --- a/sound/soc/sh/rcar/dma.c +++ b/sound/soc/sh/rcar/dma.c @@ -361,6 +361,20 @@ static u32 rsnd_dmapp_read(struct rsnd_d return ioread32(rsnd_dmapp_addr(dmac, dma, reg)); } +static void rsnd_dmapp_bset(struct rsnd_dma *dma, u32 data, u32 mask, u32 reg) +{ + struct rsnd_mod *mod = rsnd_mod_get(dma); + struct rsnd_priv *priv = rsnd_mod_to_priv(mod); + struct rsnd_dma_ctrl *dmac = rsnd_priv_to_dmac(priv); + volatile void __iomem *addr = rsnd_dmapp_addr(dmac, dma, reg); + u32 val = ioread32(addr); + + val &= ~mask; + val |= (data & mask); + + iowrite32(val, addr); +} + static int rsnd_dmapp_stop(struct rsnd_mod *mod, struct rsnd_dai_stream *io, struct rsnd_priv *priv) @@ -368,10 +382,10 @@ static int rsnd_dmapp_stop(struct rsnd_m struct rsnd_dma *dma = rsnd_mod_to_dma(mod); int i; - rsnd_dmapp_write(dma, 0, PDMACHCR); + rsnd_dmapp_bset(dma, 0, PDMACHCR_DE, PDMACHCR); for (i = 0; i < 1024; i++) { - if (0 == rsnd_dmapp_read(dma, PDMACHCR)) + if (0 == (rsnd_dmapp_read(dma, PDMACHCR) & PDMACHCR_DE)) return 0; udelay(1); } Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are queue-4.9/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch queue-4.9/asoc-rcar-clear-de-bit-only-in-pdmachcr-when-it-stops.patch queue-4.9/asoc-rsnd-rsnd_ssi_run_mods-needs-to-care-ssi_parent_mod.patch queue-4.9/asoc-rsnd-fix-sound-route-path-when-using-src6-src9.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case to the 4.9-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-intel-skylake-fix-uuid_module-memory-leak-in-failure-case.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya(a)intel.com> Date: Tue, 7 Nov 2017 16:16:19 +0530 Subject: ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case From: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya(a)intel.com> [ Upstream commit f8e066521192c7debe59127d90abbe2773577e25 ] In the loop that adds the uuid_module to the uuid_list list, allocated memory is not properly freed in the error path free uuid_list whenever any of the memory allocation in the loop fails to avoid memory leak. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya(a)intel.com> Signed-off-by: Guneshwor Singh <guneshwor.o.singh(a)intel.com> Acked-By: Vinod Koul <vinod.koul(a)intel.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/intel/skylake/skl-sst-utils.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) --- a/sound/soc/intel/skylake/skl-sst-utils.c +++ b/sound/soc/intel/skylake/skl-sst-utils.c @@ -295,6 +295,7 @@ int snd_skl_parse_uuids(struct sst_dsp * struct uuid_module *module; struct firmware stripped_fw; unsigned int safe_file; + int ret = 0; /* Get the FW pointer to derive ADSP header */ stripped_fw.data = fw->data; @@ -343,8 +344,10 @@ int snd_skl_parse_uuids(struct sst_dsp * for (i = 0; i < num_entry; i++, mod_entry++) { module = kzalloc(sizeof(*module), GFP_KERNEL); - if (!module) - return -ENOMEM; + if (!module) { + ret = -ENOMEM; + goto free_uuid_list; + } uuid_bin = (uuid_le *)mod_entry->uuid.id; memcpy(&module->uuid, uuid_bin, sizeof(module->uuid)); @@ -355,8 +358,8 @@ int snd_skl_parse_uuids(struct sst_dsp * size = sizeof(int) * mod_entry->instance_max_count; module->instance_id = devm_kzalloc(ctx->dev, size, GFP_KERNEL); if (!module->instance_id) { - kfree(module); - return -ENOMEM; + ret = -ENOMEM; + goto free_uuid_list; } list_add_tail(&module->list, &skl->uuid_list); @@ -367,6 +370,10 @@ int snd_skl_parse_uuids(struct sst_dsp * } return 0; + +free_uuid_list: + skl_freeup_uuid_list(skl); + return ret; } void skl_freeup_uuid_list(struct skl_sst *ctx) Patches currently in stable-queue which might be from pankaj.laxminarayan.bharadiya(a)intel.com are queue-4.9/asoc-intel-skylake-fix-uuid_module-memory-leak-in-failure-case.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27 to the 4.9-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: arm64-prevent-regressions-in-compressed-kernel-image-size-when-upgrading-to-binutils-2.27.patch and it can be found in the queue-4.9 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 14:12:35 CET 2017 From: Nick Desaulniers <ndesaulniers(a)google.com> Date: Fri, 27 Oct 2017 09:33:41 -0700 Subject: arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27 From: Nick Desaulniers <ndesaulniers(a)google.com> [ Upstream commit fd9dde6abcb9bfe6c6bee48834e157999f113971 ] Upon upgrading to binutils 2.27, we found that our lz4 and gzip compressed kernel images were significantly larger, resulting is 10ms boot time regressions. As noted by Rahul: "aarch64 binaries uses RELA relocations, where each relocation entry includes an addend value. This is similar to x86_64. On x86_64, the addend values are also stored at the relocation offset for relative relocations. This is an optimization: in the case where code does not need to be relocated, the loader can simply skip processing relative relocations. In binutils-2.25, both bfd and gold linkers did this for x86_64, but only the gold linker did this for aarch64. The kernel build here is using the bfd linker, which stored zeroes at the relocation offsets for relative relocations. Since a set of zeroes compresses better than a set of non-zero addend values, this behavior was resulting in much better lz4 compression. The bfd linker in binutils-2.27 is now storing the actual addend values at the relocation offsets. The behavior is now consistent with what it does for x86_64 and what gold linker does for both architectures. The change happened in this upstream commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad8980… Since a bunch of zeroes got replaced by non-zero addend values, we see the side effect of lz4 compressed image being a bit bigger. To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs" flag can be used: $ LDFLAGS="--no-apply-dynamic-relocs" make With this flag, the compressed image size is back to what it was with binutils-2.25. If the kernel is using ASLR, there aren't additional runtime costs to --no-apply-dynamic-relocs, as the relocations will need to be applied again anyway after the kernel is relocated to a random address. If the kernel is not using ASLR, then presumably the current default behavior of the linker is better. Since the static linker performed the dynamic relocs, and the kernel is not moved to a different address at load time, it can skip applying the relocations all over again." Some measurements: $ ld -v GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117 ^ $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb $ ld -v GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315 ^ pre patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb post patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb By Siqi's measurement w/ gzip: binutils 2.27 with this patch (with --no-apply-dynamic-relocs): Image 41535488 Image.gz 13404067 binutils 2.27 without this patch (without --no-apply-dynamic-relocs): Image 41535488 Image.gz 14125516 Any compression scheme should be able to get better results from the longer runs of zeros, not just GZIP and LZ4. 10ms boot time savings isn't anything to get excited about, but users of arm64+compression+bfd-2.27 should not have to pay a penalty for no runtime improvement. Reported-by: Gopinath Elanchezhian <gelanchezhian(a)google.com> Reported-by: Sindhuri Pentyala <spentyala(a)google.com> Reported-by: Wei Wang <wvw(a)google.com> Suggested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Suggested-by: Rahul Chaudhry <rahulchaudhry(a)google.com> Suggested-by: Siqi Lin <siqilin(a)google.com> Suggested-by: Stephen Hines <srhines(a)google.com> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [will: added comment to Makefile] Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/Makefile | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -14,8 +14,12 @@ LDFLAGS_vmlinux :=-p --no-undefined -X CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET) GZFLAGS :=-9 -ifneq ($(CONFIG_RELOCATABLE),) -LDFLAGS_vmlinux += -pie -shared -Bsymbolic +ifeq ($(CONFIG_RELOCATABLE), y) +# Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour +# for relative relocs, since this leads to better Image compression +# with the relocation offsets always being zero. +LDFLAGS_vmlinux += -pie -shared -Bsymbolic \ + $(call ld-option, --no-apply-dynamic-relocs) endif ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) Patches currently in stable-queue which might be from ndesaulniers(a)google.com are queue-4.9/arm64-prevent-regressions-in-compressed-kernel-image-size-when-upgrading-to-binutils-2.27.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "arm-ccn: perf: Prevent module unload while PMU is in use" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm-ccn: perf: Prevent module unload while PMU is in use to the 4.9-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-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch and it can be found in the queue-4.9 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 14:12:35 CET 2017 From: Suzuki K Poulose <suzuki.poulose(a)arm.com> Date: Fri, 3 Nov 2017 11:45:18 +0000 Subject: arm-ccn: perf: Prevent module unload while PMU is in use From: Suzuki K Poulose <suzuki.poulose(a)arm.com> [ Upstream commit c7f5828bf77dcbd61d51f4736c1d5aa35663fbb4 ] When the PMU driver is built as a module, the perf expects the pmu->module to be valid, so that the driver is prevented from being unloaded while it is in use. Fix the CCN pmu driver to fill in this field. Fixes: a33b0daab73a0 ("bus: ARM CCN PMU driver") Cc: Pawel Moll <pawel.moll(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1280,6 +1280,7 @@ static int arm_ccn_pmu_init(struct arm_c /* Perf driver registration */ ccn->dt.pmu = (struct pmu) { + .module = THIS_MODULE, .attr_groups = arm_ccn_pmu_attr_groups, .task_ctx_nr = perf_invalid_context, .event_init = arm_ccn_pmu_event_init, Patches currently in stable-queue which might be from suzuki.poulose(a)arm.com are queue-4.9/arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Prevent callback expiry timer overflow" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Prevent callback expiry timer overflow to the 4.9-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: afs-prevent-callback-expiry-timer-overflow.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Tina Ruchandani <ruchandani.tina(a)gmail.com> Date: Thu, 16 Mar 2017 16:27:46 +0000 Subject: afs: Prevent callback expiry timer overflow From: Tina Ruchandani <ruchandani.tina(a)gmail.com> [ Upstream commit 56e714312e7dbd6bb83b2f78d3ec19a404c7649f ] get_seconds() returns real wall-clock seconds. On 32-bit systems this value will overflow in year 2038 and beyond. This patch changes afs_vnode record to use ktime_get_real_seconds() instead, for the fields cb_expires and cb_expires_at. Signed-off-by: Tina Ruchandani <ruchandani.tina(a)gmail.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/fsclient.c | 2 +- fs/afs/inode.c | 7 ++++--- fs/afs/internal.h | 4 ++-- 3 files changed, 7 insertions(+), 6 deletions(-) --- a/fs/afs/fsclient.c +++ b/fs/afs/fsclient.c @@ -139,7 +139,7 @@ static void xdr_decode_AFSCallBack(const vnode->cb_version = ntohl(*bp++); vnode->cb_expiry = ntohl(*bp++); vnode->cb_type = ntohl(*bp++); - vnode->cb_expires = vnode->cb_expiry + get_seconds(); + vnode->cb_expires = vnode->cb_expiry + ktime_get_real_seconds(); *_bp = bp; } --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -245,12 +245,13 @@ struct inode *afs_iget(struct super_bloc vnode->cb_version = 0; vnode->cb_expiry = 0; vnode->cb_type = 0; - vnode->cb_expires = get_seconds(); + vnode->cb_expires = ktime_get_real_seconds(); } else { vnode->cb_version = cb->version; vnode->cb_expiry = cb->expiry; vnode->cb_type = cb->type; - vnode->cb_expires = vnode->cb_expiry + get_seconds(); + vnode->cb_expires = vnode->cb_expiry + + ktime_get_real_seconds(); } } @@ -323,7 +324,7 @@ int afs_validate(struct afs_vnode *vnode !test_bit(AFS_VNODE_CB_BROKEN, &vnode->flags) && !test_bit(AFS_VNODE_MODIFIED, &vnode->flags) && !test_bit(AFS_VNODE_ZAP_DATA, &vnode->flags)) { - if (vnode->cb_expires < get_seconds() + 10) { + if (vnode->cb_expires < ktime_get_real_seconds() + 10) { _debug("callback expired"); set_bit(AFS_VNODE_CB_BROKEN, &vnode->flags); } else { --- a/fs/afs/internal.h +++ b/fs/afs/internal.h @@ -373,8 +373,8 @@ struct afs_vnode { struct rb_node server_rb; /* link in server->fs_vnodes */ struct rb_node cb_promise; /* link in server->cb_promises */ struct work_struct cb_broken_work; /* work to be done on callback break */ - time_t cb_expires; /* time at which callback expires */ - time_t cb_expires_at; /* time used to order cb_promise */ + time64_t cb_expires; /* time at which callback expires */ + time64_t cb_expires_at; /* time used to order cb_promise */ unsigned cb_version; /* callback version */ unsigned cb_expiry; /* callback expiry time */ afs_callback_type_t cb_type; /* type of callback */ Patches currently in stable-queue which might be from ruchandani.tina(a)gmail.com are queue-4.9/afs-prevent-callback-expiry-timer-overflow.patch queue-4.9/afs-migrate-vlocation-fields-to-64-bit.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Populate group ID from vnode status" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Populate group ID from vnode status to the 4.9-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: afs-populate-group-id-from-vnode-status.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Marc Dionne <marc.dionne(a)auristor.com> Date: Thu, 16 Mar 2017 16:27:43 +0000 Subject: afs: Populate group ID from vnode status From: Marc Dionne <marc.dionne(a)auristor.com> [ Upstream commit 6186f0788b31f44affceeedc7b48eb10faea120d ] The group was hard coded to GLOBAL_ROOT_GID; use the group ID that was received from the server. Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -70,7 +70,7 @@ static int afs_inode_map_status(struct a set_nlink(inode, vnode->status.nlink); inode->i_uid = vnode->status.owner; - inode->i_gid = GLOBAL_ROOT_GID; + inode->i_gid = vnode->status.group; inode->i_size = vnode->status.size; inode->i_ctime.tv_sec = vnode->status.mtime_server; inode->i_ctime.tv_nsec = 0; Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are queue-4.9/afs-populate-group-id-from-vnode-status.patch queue-4.9/afs-adjust-mode-bits-processing.patch queue-4.9/afs-populate-and-use-client-modification-time.patch queue-4.9/afs-deal-with-an-empty-callback-array.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Populate and use client modification time" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Populate and use client modification time to the 4.9-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: afs-populate-and-use-client-modification-time.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Marc Dionne <marc.dionne(a)auristor.com> Date: Thu, 16 Mar 2017 16:27:47 +0000 Subject: afs: Populate and use client modification time From: Marc Dionne <marc.dionne(a)auristor.com> [ Upstream commit ab94f5d0dd6fd82e7eeca5e7c8096eaea0a0261f ] The inode timestamps should be set from the client time in the status received from the server, rather than the server time which is meant for internal server use. Set AFS_SET_MTIME and populate the mtime for operations that take an input status, such as file/dir creation and StoreData. If an input time is not provided the server will set the vnode times based on the current server time. In a situation where the server has some skew with the client, this could lead to the client seeing a timestamp in the future for a file that it just created or wrote. Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/fsclient.c | 18 +++++++++--------- fs/afs/inode.c | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) --- a/fs/afs/fsclient.c +++ b/fs/afs/fsclient.c @@ -105,7 +105,7 @@ static void xdr_decode_AFSFetchStatus(co vnode->vfs_inode.i_mode = mode; } - vnode->vfs_inode.i_ctime.tv_sec = status->mtime_server; + vnode->vfs_inode.i_ctime.tv_sec = status->mtime_client; vnode->vfs_inode.i_mtime = vnode->vfs_inode.i_ctime; vnode->vfs_inode.i_atime = vnode->vfs_inode.i_ctime; vnode->vfs_inode.i_version = data_version; @@ -676,8 +676,8 @@ int afs_fs_create(struct afs_server *ser memset(bp, 0, padsz); bp = (void *) bp + padsz; } - *bp++ = htonl(AFS_SET_MODE); - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MODE | AFS_SET_MTIME); + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = htonl(mode & S_IALLUGO); /* unix mode */ @@ -945,8 +945,8 @@ int afs_fs_symlink(struct afs_server *se memset(bp, 0, c_padsz); bp = (void *) bp + c_padsz; } - *bp++ = htonl(AFS_SET_MODE); - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MODE | AFS_SET_MTIME); + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = htonl(S_IRWXUGO); /* unix mode */ @@ -1145,8 +1145,8 @@ static int afs_fs_store_data64(struct af *bp++ = htonl(vnode->fid.vnode); *bp++ = htonl(vnode->fid.unique); - *bp++ = 0; /* mask */ - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MTIME); /* mask */ + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = 0; /* unix mode */ @@ -1222,8 +1222,8 @@ int afs_fs_store_data(struct afs_server *bp++ = htonl(vnode->fid.vnode); *bp++ = htonl(vnode->fid.unique); - *bp++ = 0; /* mask */ - *bp++ = 0; /* mtime */ + *bp++ = htonl(AFS_SET_MTIME); /* mask */ + *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */ *bp++ = 0; /* owner */ *bp++ = 0; /* group */ *bp++ = 0; /* unix mode */ --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -72,7 +72,7 @@ static int afs_inode_map_status(struct a inode->i_uid = vnode->status.owner; inode->i_gid = vnode->status.group; inode->i_size = vnode->status.size; - inode->i_ctime.tv_sec = vnode->status.mtime_server; + inode->i_ctime.tv_sec = vnode->status.mtime_client; inode->i_ctime.tv_nsec = 0; inode->i_atime = inode->i_mtime = inode->i_ctime; inode->i_blocks = 0; Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are queue-4.9/afs-populate-group-id-from-vnode-status.patch queue-4.9/afs-adjust-mode-bits-processing.patch queue-4.9/afs-populate-and-use-client-modification-time.patch queue-4.9/afs-deal-with-an-empty-callback-array.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Migrate vlocation fields to 64-bit" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Migrate vlocation fields to 64-bit to the 4.9-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: afs-migrate-vlocation-fields-to-64-bit.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: Tina Ruchandani <ruchandani.tina(a)gmail.com> Date: Thu, 16 Mar 2017 16:27:46 +0000 Subject: afs: Migrate vlocation fields to 64-bit From: Tina Ruchandani <ruchandani.tina(a)gmail.com> [ Upstream commit 8a79790bf0b7da216627ffb85f52cfb4adbf1e4e ] get_seconds() returns real wall-clock seconds. On 32-bit systems this value will overflow in year 2038 and beyond. This patch changes afs's vlocation record to use ktime_get_real_seconds() instead, for the fields time_of_death and update_at. Signed-off-by: Tina Ruchandani <ruchandani.tina(a)gmail.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/callback.c | 7 ++++--- fs/afs/internal.h | 7 ++++--- fs/afs/server.c | 6 +++--- fs/afs/vlocation.c | 16 +++++++++------- 4 files changed, 20 insertions(+), 16 deletions(-) --- a/fs/afs/callback.c +++ b/fs/afs/callback.c @@ -362,7 +362,7 @@ static void afs_callback_updater(struct { struct afs_server *server; struct afs_vnode *vnode, *xvnode; - time_t now; + time64_t now; long timeout; int ret; @@ -370,7 +370,7 @@ static void afs_callback_updater(struct _enter(""); - now = get_seconds(); + now = ktime_get_real_seconds(); /* find the first vnode to update */ spin_lock(&server->cb_lock); @@ -424,7 +424,8 @@ static void afs_callback_updater(struct /* and then reschedule */ _debug("reschedule"); - vnode->update_at = get_seconds() + afs_vnode_update_timeout; + vnode->update_at = ktime_get_real_seconds() + + afs_vnode_update_timeout; spin_lock(&server->cb_lock); --- a/fs/afs/internal.h +++ b/fs/afs/internal.h @@ -11,6 +11,7 @@ #include <linux/compiler.h> #include <linux/kernel.h> +#include <linux/ktime.h> #include <linux/fs.h> #include <linux/pagemap.h> #include <linux/rxrpc.h> @@ -245,7 +246,7 @@ struct afs_cache_vhash { */ struct afs_vlocation { atomic_t usage; - time_t time_of_death; /* time at which put reduced usage to 0 */ + time64_t time_of_death; /* time at which put reduced usage to 0 */ struct list_head link; /* link in cell volume location list */ struct list_head grave; /* link in master graveyard list */ struct list_head update; /* link in master update list */ @@ -256,7 +257,7 @@ struct afs_vlocation { struct afs_cache_vlocation vldb; /* volume information DB record */ struct afs_volume *vols[3]; /* volume access record pointer (index by type) */ wait_queue_head_t waitq; /* status change waitqueue */ - time_t update_at; /* time at which record should be updated */ + time64_t update_at; /* time at which record should be updated */ spinlock_t lock; /* access lock */ afs_vlocation_state_t state; /* volume location state */ unsigned short upd_rej_cnt; /* ENOMEDIUM count during update */ @@ -269,7 +270,7 @@ struct afs_vlocation { */ struct afs_server { atomic_t usage; - time_t time_of_death; /* time at which put reduced usage to 0 */ + time64_t time_of_death; /* time at which put reduced usage to 0 */ struct in_addr addr; /* server address */ struct afs_cell *cell; /* cell in which server resides */ struct list_head link; /* link in cell's server list */ --- a/fs/afs/server.c +++ b/fs/afs/server.c @@ -242,7 +242,7 @@ void afs_put_server(struct afs_server *s spin_lock(&afs_server_graveyard_lock); if (atomic_read(&server->usage) == 0) { list_move_tail(&server->grave, &afs_server_graveyard); - server->time_of_death = get_seconds(); + server->time_of_death = ktime_get_real_seconds(); queue_delayed_work(afs_wq, &afs_server_reaper, afs_server_timeout * HZ); } @@ -277,9 +277,9 @@ static void afs_reap_server(struct work_ LIST_HEAD(corpses); struct afs_server *server; unsigned long delay, expiry; - time_t now; + time64_t now; - now = get_seconds(); + now = ktime_get_real_seconds(); spin_lock(&afs_server_graveyard_lock); while (!list_empty(&afs_server_graveyard)) { --- a/fs/afs/vlocation.c +++ b/fs/afs/vlocation.c @@ -340,7 +340,8 @@ static void afs_vlocation_queue_for_upda struct afs_vlocation *xvl; /* wait at least 10 minutes before updating... */ - vl->update_at = get_seconds() + afs_vlocation_update_timeout; + vl->update_at = ktime_get_real_seconds() + + afs_vlocation_update_timeout; spin_lock(&afs_vlocation_updates_lock); @@ -506,7 +507,7 @@ void afs_put_vlocation(struct afs_vlocat if (atomic_read(&vl->usage) == 0) { _debug("buried"); list_move_tail(&vl->grave, &afs_vlocation_graveyard); - vl->time_of_death = get_seconds(); + vl->time_of_death = ktime_get_real_seconds(); queue_delayed_work(afs_wq, &afs_vlocation_reap, afs_vlocation_timeout * HZ); @@ -543,11 +544,11 @@ static void afs_vlocation_reaper(struct LIST_HEAD(corpses); struct afs_vlocation *vl; unsigned long delay, expiry; - time_t now; + time64_t now; _enter(""); - now = get_seconds(); + now = ktime_get_real_seconds(); spin_lock(&afs_vlocation_graveyard_lock); while (!list_empty(&afs_vlocation_graveyard)) { @@ -622,13 +623,13 @@ static void afs_vlocation_updater(struct { struct afs_cache_vlocation vldb; struct afs_vlocation *vl, *xvl; - time_t now; + time64_t now; long timeout; int ret; _enter(""); - now = get_seconds(); + now = ktime_get_real_seconds(); /* find a record to update */ spin_lock(&afs_vlocation_updates_lock); @@ -684,7 +685,8 @@ static void afs_vlocation_updater(struct /* and then reschedule */ _debug("reschedule"); - vl->update_at = get_seconds() + afs_vlocation_update_timeout; + vl->update_at = ktime_get_real_seconds() + + afs_vlocation_update_timeout; spin_lock(&afs_vlocation_updates_lock); Patches currently in stable-queue which might be from ruchandani.tina(a)gmail.com are queue-4.9/afs-prevent-callback-expiry-timer-overflow.patch queue-4.9/afs-migrate-vlocation-fields-to-64-bit.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Invalid op ID should abort with RXGEN_OPCODE" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Invalid op ID should abort with RXGEN_OPCODE to the 4.9-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: afs-invalid-op-id-should-abort-with-rxgen_opcode.patch and it can be found in the queue-4.9 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 14:12:34 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 16 Mar 2017 16:27:47 +0000 Subject: afs: Invalid op ID should abort with RXGEN_OPCODE From: David Howells <dhowells(a)redhat.com> [ Upstream commit 1157f153f37a8586765034470e4f00a4a6c4ce6f ] When we are given an invalid operation ID, we should abort that with RXGEN_OPCODE rather than RX_INVALID_OPERATION. Also map RXGEN_OPCODE to -ENOTSUPP. Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/afs/misc.c | 2 ++ fs/afs/rxrpc.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) --- a/fs/afs/misc.c +++ b/fs/afs/misc.c @@ -84,6 +84,8 @@ int afs_abort_to_error(u32 abort_code) case RXKADDATALEN: return -EKEYREJECTED; case RXKADILLEGALLEVEL: return -EKEYREJECTED; + case RXGEN_OPCODE: return -ENOTSUPP; + default: return -EREMOTEIO; } } --- a/fs/afs/rxrpc.c +++ b/fs/afs/rxrpc.c @@ -440,7 +440,7 @@ static void afs_deliver_to_call(struct a abort_code, -ret, "KNC"); goto do_abort; case -ENOTSUPP: - abort_code = RX_INVALID_OPERATION; + abort_code = RXGEN_OPCODE; rxrpc_kernel_abort_call(afs_socket, call->rxcall, abort_code, -ret, "KIV"); goto do_abort; Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-4.9/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-4.9/afs-fix-the-maths-in-afs_fs_store_data.patch queue-4.9/afs-populate-group-id-from-vnode-status.patch queue-4.9/afs-prevent-callback-expiry-timer-overflow.patch queue-4.9/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch queue-4.9/afs-adjust-mode-bits-processing.patch queue-4.9/rxrpc-wake-up-the-transmitter-if-rx-window-size-increases-on-the-peer.patch queue-4.9/afs-invalid-op-id-should-abort-with-rxgen_opcode.patch queue-4.9/afs-fix-page-leak-in-afs_write_begin.patch queue-4.9/afs-better-abort-and-net-error-handling.patch queue-4.9/afs-fix-missing-put_page.patch queue-4.9/afs-migrate-vlocation-fields-to-64-bit.patch queue-4.9/rxrpc-ignore-busy-packets-on-old-calls.patch queue-4.9/afs-populate-and-use-client-modification-time.patch queue-4.9/afs-fix-afs_kill_pages.patch queue-4.9/afs-fix-abort-on-signal-while-waiting-for-call-completion.patch

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror