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

[Linux-stable-mirror] Patch "dt-bindings: usb: fix reg-property port-number range" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dt-bindings: usb: fix reg-property port-number range 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: dt-bindings-usb-fix-reg-property-port-number-range.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 Tue Dec 12 10:32:42 CET 2017 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 9 Nov 2017 18:07:17 +0100 Subject: dt-bindings: usb: fix reg-property port-number range From: Johan Hovold <johan(a)kernel.org> [ Upstream commit f42ae7b0540937e00fe005812997f126aaac4bc2 ] The USB hub port-number range for USB 2.0 is 1-255 and not 1-31 which reflects an arbitrary limit set by the current Linux implementation. Note that for USB 3.1 hubs the valid range is 1-15. Increase the documented valid range in the binding to 255, which is the maximum allowed by the specifications. Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/devicetree/bindings/usb/usb-device.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Documentation/devicetree/bindings/usb/usb-device.txt +++ b/Documentation/devicetree/bindings/usb/usb-device.txt @@ -11,7 +11,7 @@ Required properties: be used, but a device adhering to this binding may leave out all except for usbVID,PID. - reg: the port number which this device is connecting to, the range - is 1-31. + is 1-255. Example: Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.14/serdev-ttyport-fix-null-deref-on-hangup.patch queue-4.14/dt-bindings-usb-fix-reg-property-port-number-range.patch queue-4.14/serdev-ttyport-fix-tty-locking-in-close.patch queue-4.14/clk-qcom-common-fix-legacy-board-clock-registration.patch queue-4.14/serdev-ttyport-add-missing-receive_buf-sanity-checks.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "coccinelle: fix parallel build with CHECK=scripts/coccicheck" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled coccinelle: fix parallel build with CHECK=scripts/coccicheck 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: coccinelle-fix-parallel-build-with-check-scripts-coccicheck.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 Tue Dec 12 10:32:42 CET 2017 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Tue, 14 Nov 2017 20:38:07 +0900 Subject: coccinelle: fix parallel build with CHECK=scripts/coccicheck From: Masahiro Yamada <yamada.masahiro(a)socionext.com> [ Upstream commit d7059ca0147adcd495f3c5b41f260e1ac55bb679 ] The command "make -j8 C=1 CHECK=scripts/coccicheck" produces lots of "coccicheck failed" error messages. Julia Lawall explained the Coccinelle behavior as follows: "The problem on the Coccinelle side is that it uses a subdirectory with the name of the semantic patch to store standard output and standard error for the different threads. I didn't want to use a name with the pid, so that one could easily find this information while Coccinelle is running. Normally the subdirectory is cleaned up when Coccinelle completes, so there is only one of them at a time. Maybe it is best to just add the pid. There is the risk that these subdirectories will accumulate if Coccinelle crashes in a way such that they don't get cleaned up, but Coccinelle could print a warning if it detects this case, rather than failing." When scripts/coccicheck is used as CHECK tool and -j option is given to Make, the whole of build process runs in parallel. So, multiple processes try to get access to the same subdirectory. I notice spatch creates the subdirectory only when it runs in parallel (i.e. --jobs <N> is given and <N> is greater than 1). Setting NPROC=1 is a reasonable solution; spatch does not create the subdirectory. Besides, ONLINE=1 mode takes a single file input for each spatch invocation, so there is no reason to parallelize it in the first place. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Acked-by: Julia Lawall <Julia.Lawall(a)lip6.fr> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- scripts/coccicheck | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/scripts/coccicheck +++ b/scripts/coccicheck @@ -30,12 +30,6 @@ else VERBOSE=0 fi -if [ -z "$J" ]; then - NPROC=$(getconf _NPROCESSORS_ONLN) -else - NPROC="$J" -fi - FLAGS="--very-quiet" # You can use SPFLAGS to append extra arguments to coccicheck or override any @@ -70,6 +64,9 @@ if [ "$C" = "1" -o "$C" = "2" ]; then # Take only the last argument, which is the C file to test shift $(( $# - 1 )) OPTIONS="$COCCIINCLUDE $1" + + # No need to parallelize Coccinelle since this mode takes one input file. + NPROC=1 else ONLINE=0 if [ "$KBUILD_EXTMOD" = "" ] ; then @@ -77,6 +74,12 @@ else else OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE" fi + + if [ -z "$J" ]; then + NPROC=$(getconf _NPROCESSORS_ONLN) + else + NPROC="$J" + fi fi if [ "$KBUILD_EXTMOD" != "" ] ; then Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are queue-4.14/kbuild-rpm-pkg-fix-jobserver-unavailable-warning.patch queue-4.14/firmware-cleanup-firmware_in_kernel-message.patch queue-4.14/clk-uniphier-fix-dapll2-clock-rate-of-pro5.patch queue-4.14/kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch queue-4.14/coccinelle-fix-parallel-build-with-check-scripts-coccicheck.patch queue-4.14/kbuild-pkg-use-transform-option-to-prefix-paths-in-tar.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "dm raid: fix panic when attempting to force a raid to sync" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dm raid: fix panic when attempting to force a raid to sync 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: dm-raid-fix-panic-when-attempting-to-force-a-raid-to-sync.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 Tue Dec 12 10:32:42 CET 2017 From: Heinz Mauelshagen <heinzm(a)redhat.com> Date: Thu, 2 Nov 2017 19:58:28 +0100 Subject: dm raid: fix panic when attempting to force a raid to sync From: Heinz Mauelshagen <heinzm(a)redhat.com> [ Upstream commit 233978449074ca7e45d9c959f9ec612d1b852893 ] Requesting a sync on an active raid device via a table reload (see 'sync' parameter in Documentation/device-mapper/dm-raid.txt) skips the super_load() call that defines the superblock size (rdev->sb_size) -- resulting in an oops if/when super_sync()->memset() is called. Fix by moving the initialization of the superblock start and size out of super_load() to the caller (analyse_superblocks). Signed-off-by: Heinz Mauelshagen <heinzm(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/dm-raid.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -2143,13 +2143,6 @@ static int super_load(struct md_rdev *rd struct dm_raid_superblock *refsb; uint64_t events_sb, events_refsb; - rdev->sb_start = 0; - rdev->sb_size = bdev_logical_block_size(rdev->meta_bdev); - if (rdev->sb_size < sizeof(*sb) || rdev->sb_size > PAGE_SIZE) { - DMERR("superblock size of a logical block is no longer valid"); - return -EINVAL; - } - r = read_disk_sb(rdev, rdev->sb_size, false); if (r) return r; @@ -2494,6 +2487,17 @@ static int analyse_superblocks(struct dm if (test_bit(Journal, &rdev->flags)) continue; + if (!rdev->meta_bdev) + continue; + + /* Set superblock offset/size for metadata device. */ + rdev->sb_start = 0; + rdev->sb_size = bdev_logical_block_size(rdev->meta_bdev); + if (rdev->sb_size < sizeof(struct dm_raid_superblock) || rdev->sb_size > PAGE_SIZE) { + DMERR("superblock size of a logical block is no longer valid"); + return -EINVAL; + } + /* * Skipping super_load due to CTR_FLAG_SYNC will cause * the array to undergo initialization again as @@ -2506,9 +2510,6 @@ static int analyse_superblocks(struct dm if (test_bit(__CTR_FLAG_SYNC, &rs->ctr_flags)) continue; - if (!rdev->meta_bdev) - continue; - r = super_load(rdev, freshest); switch (r) { Patches currently in stable-queue which might be from heinzm(a)redhat.com are queue-4.14/dm-raid-fix-panic-when-attempting-to-force-a-raid-to-sync.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: uniphier: fix DAPLL2 clock rate of Pro5" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: uniphier: fix DAPLL2 clock rate of Pro5 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-uniphier-fix-dapll2-clock-rate-of-pro5.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 Tue Dec 12 10:32:42 CET 2017 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Thu, 5 Oct 2017 11:32:59 +0900 Subject: clk: uniphier: fix DAPLL2 clock rate of Pro5 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> [ Upstream commit 67affb78a4e4feb837953e3434c8402a5c3b272f ] The parent of DAPLL2 should be DAPLL1. Fix the clock connection. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.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/uniphier/clk-uniphier-sys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/uniphier/clk-uniphier-sys.c +++ b/drivers/clk/uniphier/clk-uniphier-sys.c @@ -123,7 +123,7 @@ const struct uniphier_clk_data uniphier_ const struct uniphier_clk_data uniphier_pro5_sys_clk_data[] = { UNIPHIER_CLK_FACTOR("spll", -1, "ref", 120, 1), /* 2400 MHz */ UNIPHIER_CLK_FACTOR("dapll1", -1, "ref", 128, 1), /* 2560 MHz */ - UNIPHIER_CLK_FACTOR("dapll2", -1, "ref", 144, 125), /* 2949.12 MHz */ + UNIPHIER_CLK_FACTOR("dapll2", -1, "dapll1", 144, 125), /* 2949.12 MHz */ UNIPHIER_CLK_FACTOR("uart", 0, "dapll2", 1, 40), UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 48), UNIPHIER_PRO5_SYS_CLK_NAND(2), Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are queue-4.14/kbuild-rpm-pkg-fix-jobserver-unavailable-warning.patch queue-4.14/firmware-cleanup-firmware_in_kernel-message.patch queue-4.14/clk-uniphier-fix-dapll2-clock-rate-of-pro5.patch queue-4.14/kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch queue-4.14/coccinelle-fix-parallel-build-with-check-scripts-coccicheck.patch queue-4.14/kbuild-pkg-use-transform-option-to-prefix-paths-in-tar.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: stm32h7: fix test of clock config" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: stm32h7: fix test of clock config 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-stm32h7-fix-test-of-clock-config.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 Tue Dec 12 10:32:42 CET 2017 From: Gabriel Fernandez <gabriel.fernandez(a)st.com> Date: Wed, 11 Oct 2017 08:57:24 +0200 Subject: clk: stm32h7: fix test of clock config From: Gabriel Fernandez <gabriel.fernandez(a)st.com> [ Upstream commit c1ea839c41d049604a3f64ef72712d1c7c6639d0 ] fix test of composite clock config (bad copy / past) Signed-off-by: Gabriel Fernandez <gabriel.fernandez(a)st.com> Fixes: 3e4d618b0722 ("clk: stm32h7: Add stm32h743 clock driver") 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/clk-stm32h7.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/clk/clk-stm32h7.c +++ b/drivers/clk/clk-stm32h7.c @@ -384,7 +384,7 @@ static void get_cfg_composite_div(const mux_ops = div_ops = gate_ops = NULL; mux_hw = div_hw = gate_hw = NULL; - if (gcfg->mux && gcfg->mux) { + if (gcfg->mux && cfg->mux) { mux = _get_cmux(base + cfg->mux->offset, cfg->mux->shift, cfg->mux->width, @@ -410,7 +410,7 @@ static void get_cfg_composite_div(const } } - if (gcfg->gate && gcfg->gate) { + if (gcfg->gate && cfg->gate) { gate = _get_cgate(base + cfg->gate->offset, cfg->gate->bit_idx, gcfg->gate->flags, lock); Patches currently in stable-queue which might be from gabriel.fernandez(a)st.com are queue-4.14/clk-stm32h7-fix-test-of-clock-config.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: sunxi-ng: a83t: Fix i2c buses bits" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: sunxi-ng: a83t: Fix i2c buses bits 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-sunxi-ng-a83t-fix-i2c-buses-bits.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 Tue Dec 12 10:32:42 CET 2017 From: Mylene JOSSERAND <mylene.josserand(a)free-electrons.com> Date: Sun, 5 Nov 2017 17:51:34 +0100 Subject: clk: sunxi-ng: a83t: Fix i2c buses bits From: Mylene JOSSERAND <mylene.josserand(a)free-electrons.com> [ Upstream commit cc54c0955d6f8618a38a999eecdc3d95306b90de ] i2c1 and i2c2 bits for CCU are not bit 0 but bit 1 and bit 2. Because of that, the i2c0 (bit 0) was not correctly configured. Fixed the correct bits for i2c1 and i2c2. Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU") Signed-off-by: Mylène Josserand <mylene.josserand(a)free-electrons.com> Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.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/sunxi-ng/ccu-sun8i-a83t.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c @@ -354,9 +354,9 @@ static SUNXI_CCU_GATE(bus_tdm_clk, "bus- static SUNXI_CCU_GATE(bus_i2c0_clk, "bus-i2c0", "apb2", 0x06c, BIT(0), 0); static SUNXI_CCU_GATE(bus_i2c1_clk, "bus-i2c1", "apb2", - 0x06c, BIT(0), 0); + 0x06c, BIT(1), 0); static SUNXI_CCU_GATE(bus_i2c2_clk, "bus-i2c2", "apb2", - 0x06c, BIT(0), 0); + 0x06c, BIT(2), 0); static SUNXI_CCU_GATE(bus_uart0_clk, "bus-uart0", "apb2", 0x06c, BIT(16), 0); static SUNXI_CCU_GATE(bus_uart1_clk, "bus-uart1", "apb2", Patches currently in stable-queue which might be from mylene.josserand(a)free-electrons.com are queue-4.14/clk-sunxi-ng-a83t-fix-i2c-buses-bits.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: qcom: common: fix legacy board-clock registration" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: qcom: common: fix legacy board-clock registration 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-qcom-common-fix-legacy-board-clock-registration.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 Tue Dec 12 10:32:42 CET 2017 From: Johan Hovold <johan(a)kernel.org> Date: Sat, 11 Nov 2017 17:29:28 +0100 Subject: clk: qcom: common: fix legacy board-clock registration From: Johan Hovold <johan(a)kernel.org> [ Upstream commit 43a51019cc8ff1b1cd2ba72e86563beb40d356fc ] Make sure to search only the child nodes of "/clocks", rather than the whole device-tree depth-first starting at "/clocks" when determining whether to register a fixed clock in the legacy board-clock registration helper. Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards compatibly") Signed-off-by: Johan Hovold <johan(a)kernel.org> 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/qcom/common.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/clk/qcom/common.c +++ b/drivers/clk/qcom/common.c @@ -143,8 +143,10 @@ static int _qcom_cc_register_board_clk(s int ret; clocks_node = of_find_node_by_path("/clocks"); - if (clocks_node) - node = of_find_node_by_name(clocks_node, path); + if (clocks_node) { + node = of_get_child_by_name(clocks_node, path); + of_node_put(clocks_node); + } if (!node) { fixed = devm_kzalloc(dev, sizeof(*fixed), GFP_KERNEL); Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.14/serdev-ttyport-fix-null-deref-on-hangup.patch queue-4.14/dt-bindings-usb-fix-reg-property-port-number-range.patch queue-4.14/serdev-ttyport-fix-tty-locking-in-close.patch queue-4.14/clk-qcom-common-fix-legacy-board-clock-registration.patch queue-4.14/serdev-ttyport-add-missing-receive_buf-sanity-checks.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "bpf: fix lockdep splat" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bpf: fix lockdep splat 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: bpf-fix-lockdep-splat.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 Tue Dec 12 10:32:42 CET 2017 From: Eric Dumazet <edumazet(a)google.com> Date: Tue, 14 Nov 2017 17:15:50 -0800 Subject: bpf: fix lockdep splat From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 89ad2fa3f043a1e8daae193bcb5fe34d5f8caf28 ] pcpu_freelist_pop() needs the same lockdep awareness than pcpu_freelist_populate() to avoid a false positive. [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] switchto-defaul/12508 [HC0[0]:SC0[6]:HE0:SE0] is trying to acquire: (&htab->buckets[i].lock){......}, at: [<ffffffff9dc099cb>] __htab_percpu_map_update_elem+0x1cb/0x300 and this task is already holding: (dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2){+.-...}, at: [<ffffffff9e135848>] __dev_queue_xmit+0 x868/0x1240 which would create a new lock dependency: (dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2){+.-...} -> (&htab->buckets[i].lock){......} but this new dependency connects a SOFTIRQ-irq-safe lock: (dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2){+.-...} ... which became SOFTIRQ-irq-safe at: [<ffffffff9db5931b>] __lock_acquire+0x42b/0x1f10 [<ffffffff9db5b32c>] lock_acquire+0xbc/0x1b0 [<ffffffff9da05e38>] _raw_spin_lock+0x38/0x50 [<ffffffff9e135848>] __dev_queue_xmit+0x868/0x1240 [<ffffffff9e136240>] dev_queue_xmit+0x10/0x20 [<ffffffff9e1965d9>] ip_finish_output2+0x439/0x590 [<ffffffff9e197410>] ip_finish_output+0x150/0x2f0 [<ffffffff9e19886d>] ip_output+0x7d/0x260 [<ffffffff9e19789e>] ip_local_out+0x5e/0xe0 [<ffffffff9e197b25>] ip_queue_xmit+0x205/0x620 [<ffffffff9e1b8398>] tcp_transmit_skb+0x5a8/0xcb0 [<ffffffff9e1ba152>] tcp_write_xmit+0x242/0x1070 [<ffffffff9e1baffc>] __tcp_push_pending_frames+0x3c/0xf0 [<ffffffff9e1b3472>] tcp_rcv_established+0x312/0x700 [<ffffffff9e1c1acc>] tcp_v4_do_rcv+0x11c/0x200 [<ffffffff9e1c3dc2>] tcp_v4_rcv+0xaa2/0xc30 [<ffffffff9e191107>] ip_local_deliver_finish+0xa7/0x240 [<ffffffff9e191a36>] ip_local_deliver+0x66/0x200 [<ffffffff9e19137d>] ip_rcv_finish+0xdd/0x560 [<ffffffff9e191e65>] ip_rcv+0x295/0x510 [<ffffffff9e12ff88>] __netif_receive_skb_core+0x988/0x1020 [<ffffffff9e130641>] __netif_receive_skb+0x21/0x70 [<ffffffff9e1306ff>] process_backlog+0x6f/0x230 [<ffffffff9e132129>] net_rx_action+0x229/0x420 [<ffffffff9da07ee8>] __do_softirq+0xd8/0x43d [<ffffffff9e282bcc>] do_softirq_own_stack+0x1c/0x30 [<ffffffff9dafc2f5>] do_softirq+0x55/0x60 [<ffffffff9dafc3a8>] __local_bh_enable_ip+0xa8/0xb0 [<ffffffff9db4c727>] cpu_startup_entry+0x1c7/0x500 [<ffffffff9daab333>] start_secondary+0x113/0x140 to a SOFTIRQ-irq-unsafe lock: (&head->lock){+.+...} ... which became SOFTIRQ-irq-unsafe at: ... [<ffffffff9db5971f>] __lock_acquire+0x82f/0x1f10 [<ffffffff9db5b32c>] lock_acquire+0xbc/0x1b0 [<ffffffff9da05e38>] _raw_spin_lock+0x38/0x50 [<ffffffff9dc0b7fa>] pcpu_freelist_pop+0x7a/0xb0 [<ffffffff9dc08b2c>] htab_map_alloc+0x50c/0x5f0 [<ffffffff9dc00dc5>] SyS_bpf+0x265/0x1200 [<ffffffff9e28195f>] entry_SYSCALL_64_fastpath+0x12/0x17 other info that might help us debug this: Chain exists of: dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2 --> &htab->buckets[i].lock --> &head->lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&head->lock); local_irq_disable(); lock(dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2); lock(&htab->buckets[i].lock); <Interrupt> lock(dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2); *** DEADLOCK *** Fixes: e19494edab82 ("bpf: introduce percpu_freelist") Signed-off-by: Eric Dumazet <edumazet(a)google.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> --- kernel/bpf/percpu_freelist.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/kernel/bpf/percpu_freelist.c +++ b/kernel/bpf/percpu_freelist.c @@ -78,8 +78,10 @@ struct pcpu_freelist_node *pcpu_freelist { struct pcpu_freelist_head *head; struct pcpu_freelist_node *node; + unsigned long flags; int orig_cpu, cpu; + local_irq_save(flags); orig_cpu = cpu = raw_smp_processor_id(); while (1) { head = per_cpu_ptr(s->freelist, cpu); @@ -87,14 +89,16 @@ struct pcpu_freelist_node *pcpu_freelist node = head->first; if (node) { head->first = node->next; - raw_spin_unlock(&head->lock); + raw_spin_unlock_irqrestore(&head->lock, flags); return node; } raw_spin_unlock(&head->lock); cpu = cpumask_next(cpu, cpu_possible_mask); if (cpu >= nr_cpu_ids) cpu = 0; - if (cpu == orig_cpu) + if (cpu == orig_cpu) { + local_irq_restore(flags); return NULL; + } } } Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.14/bpf-fix-lockdep-splat.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: hi3660: fix incorrect uart3 clock freqency" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: hi3660: fix incorrect uart3 clock freqency 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-hi3660-fix-incorrect-uart3-clock-freqency.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 Tue Dec 12 10:32:42 CET 2017 From: Zhong Kaihua <zhongkaihua(a)huawei.com> Date: Mon, 7 Aug 2017 22:51:56 +0800 Subject: clk: hi3660: fix incorrect uart3 clock freqency From: Zhong Kaihua <zhongkaihua(a)huawei.com> [ Upstream commit d33fb1b9f0fcb67f2b9f8b1891465a088a9480f8 ] UART3 clock rate is doubled in previous commit. This error is not detected until recently a mezzanine board which makes real use of uart3 port (through LS connector of 96boards) was setup and tested on hi3660-hikey960 board. This patch changes clock source rate of clk_factor_uart3 to 100000000. Signed-off-by: Zhong Kaihua <zhongkaihua(a)huawei.com> Signed-off-by: Guodong Xu <guodong.xu(a)linaro.org> 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/hisilicon/clk-hi3660.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/hisilicon/clk-hi3660.c +++ b/drivers/clk/hisilicon/clk-hi3660.c @@ -34,7 +34,7 @@ static const struct hisi_fixed_rate_cloc /* crgctrl */ static const struct hisi_fixed_factor_clock hi3660_crg_fixed_factor_clks[] = { - { HI3660_FACTOR_UART3, "clk_factor_uart3", "iomcu_peri0", 1, 8, 0, }, + { HI3660_FACTOR_UART3, "clk_factor_uart3", "iomcu_peri0", 1, 16, 0, }, { HI3660_CLK_FACTOR_MMC, "clk_factor_mmc", "clkin_sys", 1, 6, 0, }, { HI3660_CLK_GATE_I2C0, "clk_gate_i2c0", "clk_i2c0_iomcu", 1, 4, 0, }, { HI3660_CLK_GATE_I2C1, "clk_gate_i2c1", "clk_i2c1_iomcu", 1, 4, 0, }, Patches currently in stable-queue which might be from zhongkaihua(a)huawei.com are queue-4.14/clk-hi3660-fix-incorrect-uart3-clock-freqency.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "bnxt_re: changing the ip address shouldn't affect new connections" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bnxt_re: changing the ip address shouldn't affect new connections 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: bnxt_re-changing-the-ip-address-shouldn-t-affect-new-connections.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 Tue Dec 12 10:32:42 CET 2017 From: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com> Date: Fri, 3 Nov 2017 02:39:04 +0530 Subject: bnxt_re: changing the ip address shouldn't affect new connections From: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com> [ Upstream commit 063fb5bd1a01937094f40169a20e4aa5ca030db1 ] While adding a new gid, the driver currently does not return the context back to the stack. A subsequent del_gid() (e.g, when ip address is changed) doesn't find the right context in the driver and it ends up dropping that request. This results in the HW caching a stale gid entry and traffic fails because of that. Fix by returning the proper context in bnxt_re_add_gid(). Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/bnxt_re/ib_verbs.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c @@ -394,6 +394,7 @@ int bnxt_re_add_gid(struct ib_device *ib ctx->idx = tbl_idx; ctx->refcnt = 1; ctx_tbl[tbl_idx] = ctx; + *context = ctx; return rc; } Patches currently in stable-queue which might be from sriharsha.basavapatna(a)broadcom.com are queue-4.14/bnxt_re-changing-the-ip-address-shouldn-t-affect-new-connections.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "blk-mq: Avoid that request queue removal can trigger list corruption" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-mq: Avoid that request queue removal can trigger list corruption 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-avoid-that-request-queue-removal-can-trigger-list-corruption.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 Tue Dec 12 10:32:42 CET 2017 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Wed, 8 Nov 2017 10:23:45 -0800 Subject: blk-mq: Avoid that request queue removal can trigger list corruption From: Bart Van Assche <bart.vanassche(a)wdc.com> [ Upstream commit aba7afc5671c23beade64d10caf86e24a9105dab ] Avoid that removal of a request queue sporadically triggers the following warning: list_del corruption. next->prev should be ffff8807d649b970, but was 6b6b6b6b6b6b6b6b WARNING: CPU: 3 PID: 342 at lib/list_debug.c:56 __list_del_entry_valid+0x92/0xa0 Call Trace: process_one_work+0x11b/0x660 worker_thread+0x3d/0x3b0 kthread+0x129/0x140 ret_from_fork+0x27/0x40 Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Johannes Thumshirn <jthumshirn(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> --- block/blk-core.c | 1 + 1 file changed, 1 insertion(+) --- a/block/blk-core.c +++ b/block/blk-core.c @@ -339,6 +339,7 @@ void blk_sync_queue(struct request_queue struct blk_mq_hw_ctx *hctx; int i; + cancel_delayed_work_sync(&q->requeue_work); queue_for_each_hw_ctx(q, hctx, i) cancel_delayed_work_sync(&hctx->run_work); } else { Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.14/blk-mq-avoid-that-request-queue-removal-can-trigger-list-corruption.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "block: wake up all tasks blocked in get_request()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled block: wake up all tasks blocked in get_request() 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: block-wake-up-all-tasks-blocked-in-get_request.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 Tue Dec 12 10:32:42 CET 2017 From: Ming Lei <ming.lei(a)redhat.com> Date: Thu, 16 Nov 2017 08:08:44 +0800 Subject: block: wake up all tasks blocked in get_request() From: Ming Lei <ming.lei(a)redhat.com> [ Upstream commit 34d9715ac1edd50285168dd8d80c972739a4f6a4 ] Once blk_set_queue_dying() is done in blk_cleanup_queue(), we call blk_freeze_queue() and wait for q->q_usage_counter becoming zero. But if there are tasks blocked in get_request(), q->q_usage_counter can never become zero. So we have to wake up all these tasks in blk_set_queue_dying() first. Fixes: 3ef28e83ab157997 ("block: generic request_queue reference counting") 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-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/block/blk-core.c +++ b/block/blk-core.c @@ -605,8 +605,8 @@ void blk_set_queue_dying(struct request_ spin_lock_irq(q->queue_lock); blk_queue_for_each_rl(rl, q) { if (rl->rq_pool) { - wake_up(&rl->wait[BLK_RW_SYNC]); - wake_up(&rl->wait[BLK_RW_ASYNC]); + wake_up_all(&rl->wait[BLK_RW_SYNC]); + wake_up_all(&rl->wait[BLK_RW_ASYNC]); } } spin_unlock_irq(q->queue_lock); Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.14/block-wake-up-all-tasks-blocked-in-get_request.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "audit: Allow auditd to set pid to 0 to end auditing" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled audit: Allow auditd to set pid to 0 to end auditing 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: audit-allow-auditd-to-set-pid-to-0-to-end-auditing.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 Tue Dec 12 10:32:42 CET 2017 From: Steve Grubb <sgrubb(a)redhat.com> Date: Tue, 17 Oct 2017 18:29:22 -0400 Subject: audit: Allow auditd to set pid to 0 to end auditing From: Steve Grubb <sgrubb(a)redhat.com> [ Upstream commit 33e8a907804428109ce1d12301c3365d619cc4df ] The API to end auditing has historically been for auditd to set the pid to 0. This patch restores that functionality. See: https://github.com/linux-audit/audit-kernel/issues/69 Reviewed-by: Richard Guy Briggs <rgb(a)redhat.com> Signed-off-by: Steve Grubb <sgrubb(a)redhat.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/audit.c | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) --- a/kernel/audit.c +++ b/kernel/audit.c @@ -1197,25 +1197,28 @@ static int audit_receive_msg(struct sk_b pid_t auditd_pid; struct pid *req_pid = task_tgid(current); - /* sanity check - PID values must match */ - if (new_pid != pid_vnr(req_pid)) + /* Sanity check - PID values must match. Setting + * pid to 0 is how auditd ends auditing. */ + if (new_pid && (new_pid != pid_vnr(req_pid))) return -EINVAL; /* test the auditd connection */ audit_replace(req_pid); auditd_pid = auditd_pid_vnr(); - /* only the current auditd can unregister itself */ - if ((!new_pid) && (new_pid != auditd_pid)) { - audit_log_config_change("audit_pid", new_pid, - auditd_pid, 0); - return -EACCES; - } - /* replacing a healthy auditd is not allowed */ - if (auditd_pid && new_pid) { - audit_log_config_change("audit_pid", new_pid, - auditd_pid, 0); - return -EEXIST; + if (auditd_pid) { + /* replacing a healthy auditd is not allowed */ + if (new_pid) { + audit_log_config_change("audit_pid", + new_pid, auditd_pid, 0); + return -EEXIST; + } + /* only current auditd can unregister itself */ + if (pid_vnr(req_pid) != auditd_pid) { + audit_log_config_change("audit_pid", + new_pid, auditd_pid, 0); + return -EACCES; + } } if (new_pid) { Patches currently in stable-queue which might be from sgrubb(a)redhat.com are queue-4.14/audit-allow-auditd-to-set-pid-to-0-to-end-auditing.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "audit: ensure that 'audit=1' actually enables audit for PID 1" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled audit: ensure that 'audit=1' actually enables audit for PID 1 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: audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.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 Tue Dec 12 10:32:42 CET 2017 From: Paul Moore <paul(a)paul-moore.com> Date: Fri, 1 Sep 2017 09:44:34 -0400 Subject: audit: ensure that 'audit=1' actually enables audit for PID 1 From: Paul Moore <paul(a)paul-moore.com> [ Upstream commit 173743dd99a49c956b124a74c8aacb0384739a4c ] Prior to this patch we enabled audit in audit_init(), which is too late for PID 1 as the standard initcalls are run after the PID 1 task is forked. This means that we never allocate an audit_context (see audit_alloc()) for PID 1 and therefore miss a lot of audit events generated by PID 1. This patch enables audit as early as possible to help ensure that when PID 1 is forked it can allocate an audit_context if required. Reviewed-by: Richard Guy Briggs <rgb(a)redhat.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/audit.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/kernel/audit.c +++ b/kernel/audit.c @@ -85,13 +85,13 @@ static int audit_initialized; #define AUDIT_OFF 0 #define AUDIT_ON 1 #define AUDIT_LOCKED 2 -u32 audit_enabled; -u32 audit_ever_enabled; +u32 audit_enabled = AUDIT_OFF; +u32 audit_ever_enabled = !!AUDIT_OFF; EXPORT_SYMBOL_GPL(audit_enabled); /* Default state when kernel boots without any parameters. */ -static u32 audit_default; +static u32 audit_default = AUDIT_OFF; /* If auditing cannot proceed, audit_failure selects what happens. */ static u32 audit_failure = AUDIT_FAIL_PRINTK; @@ -1552,8 +1552,6 @@ static int __init audit_init(void) register_pernet_subsys(&audit_net_ops); audit_initialized = AUDIT_INITIALIZED; - audit_enabled = audit_default; - audit_ever_enabled |= !!audit_default; kauditd_task = kthread_run(kauditd_thread, NULL, "kauditd"); if (IS_ERR(kauditd_task)) { @@ -1575,6 +1573,8 @@ static int __init audit_enable(char *str audit_default = !!simple_strtol(str, NULL, 0); if (!audit_default) audit_initialized = AUDIT_DISABLED; + audit_enabled = audit_default; + audit_ever_enabled = !!audit_enabled; pr_info("%s\n", audit_default ? "enabled (after initialization)" : "disabled (until reboot)"); Patches currently in stable-queue which might be from paul(a)paul-moore.com are queue-4.14/ib-core-only-enforce-security-for-infiniband.patch queue-4.14/audit-allow-auditd-to-set-pid-to-0-to-end-auditing.patch queue-4.14/audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Fix total-length calculation for multiple-page send" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Fix total-length calculation for multiple-page send 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: afs-fix-total-length-calculation-for-multiple-page-send.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 Tue Dec 12 10:32:42 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 2 Nov 2017 15:27:51 +0000 Subject: afs: Fix total-length calculation for multiple-page send From: David Howells <dhowells(a)redhat.com> [ Upstream commit 1199db603511d7463d9d3840f96f61967affc766 ] Fix the total-length calculation in afs_make_call() when the operation being dispatched has data from a series of pages attached. Despite the patched code looking like that it should reduce mathematically to the current code, it doesn't because the 32-bit unsigned arithmetic being used to calculate the page-offset-difference doesn't correctly extend to a 64-bit value when the result is effectively negative. Without this, some FS.StoreData operations that span multiple pages fail, reporting too little or too much data. 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/rxrpc.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/fs/afs/rxrpc.c +++ b/fs/afs/rxrpc.c @@ -377,8 +377,17 @@ int afs_make_call(struct in_addr *addr, */ tx_total_len = call->request_size; if (call->send_pages) { - tx_total_len += call->last_to - call->first_offset; - tx_total_len += (call->last - call->first) * PAGE_SIZE; + if (call->last == call->first) { + tx_total_len += call->last_to - call->first_offset; + } else { + /* It looks mathematically like you should be able to + * combine the following lines with the ones above, but + * unsigned arithmetic is fun when it wraps... + */ + tx_total_len += PAGE_SIZE - call->first_offset; + tx_total_len += call->last_to; + tx_total_len += (call->last - call->first - 1) * PAGE_SIZE; + } } /* create a call */ Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-4.14/x.509-reject-invalid-bit-string-for-subjectpublickey.patch queue-4.14/asn.1-check-for-error-from-asn1_op_end__act-actions.patch queue-4.14/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.14/afs-fix-total-length-calculation-for-multiple-page-send.patch queue-4.14/afs-connect-up-the-cb.probeuuid.patch queue-4.14/asn.1-fix-out-of-bounds-read-when-parsing-indefinite-length-item.patch queue-4.14/keys-reject-null-restriction-string-when-type-is-specified.patch queue-4.14/x.509-fix-comparisons-of-pkey_algo.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "atm: horizon: Fix irq release error" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled atm: horizon: Fix irq release error 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: atm-horizon-fix-irq-release-error.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 Tue Dec 12 10:32:42 CET 2017 From: Arvind Yadav <arvind.yadav.cs(a)gmail.com> Date: Tue, 14 Nov 2017 13:42:38 +0530 Subject: atm: horizon: Fix irq release error From: Arvind Yadav <arvind.yadav.cs(a)gmail.com> [ Upstream commit bde533f2ea607cbbbe76ef8738b36243939a7bc2 ] atm_dev_register() can fail here and passed parameters to free irq which is not initialised. Initialization of 'dev->irq' happened after the 'goto out_free_irq'. So using 'irq' insted of 'dev->irq' in free_irq(). Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.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/atm/horizon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/atm/horizon.c +++ b/drivers/atm/horizon.c @@ -2803,7 +2803,7 @@ out: return err; out_free_irq: - free_irq(dev->irq, dev); + free_irq(irq, dev); out_free: kfree(dev); out_release: Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are queue-4.14/atm-horizon-fix-irq-release-error.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "apparmor: fix leak of null profile name if profile allocation fails" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled apparmor: fix leak of null profile name if profile allocation 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: apparmor-fix-leak-of-null-profile-name-if-profile-allocation-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 Tue Dec 12 10:32:42 CET 2017 From: John Johansen <john.johansen(a)canonical.com> Date: Wed, 15 Nov 2017 15:25:30 -0800 Subject: apparmor: fix leak of null profile name if profile allocation fails From: John Johansen <john.johansen(a)canonical.com> [ Upstream commit 4633307e5ed6128975595df43f796a10c41d11c1 ] Fixes: d07881d2edb0 ("apparmor: move new_null_profile to after profile lookup fns()") Reported-by: Seth Arnold <seth.arnold(a)canonical.com> Signed-off-by: John Johansen <john.johansen(a)canonical.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/apparmor/policy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/security/apparmor/policy.c +++ b/security/apparmor/policy.c @@ -502,7 +502,7 @@ struct aa_profile *aa_new_null_profile(s { struct aa_profile *p, *profile; const char *bname; - char *name; + char *name = NULL; AA_BUG(!parent); @@ -562,6 +562,7 @@ out: return profile; fail: + kfree(name); aa_free_profile(profile); return NULL; } Patches currently in stable-queue which might be from john.johansen(a)canonical.com are queue-4.14/apparmor-fix-leak-of-null-profile-name-if-profile-allocation-fails.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "afs: Connect up the CB.ProbeUuid" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled afs: Connect up the CB.ProbeUuid 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: afs-connect-up-the-cb.probeuuid.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 Tue Dec 12 10:32:42 CET 2017 From: David Howells <dhowells(a)redhat.com> Date: Thu, 2 Nov 2017 15:27:48 +0000 Subject: afs: Connect up the CB.ProbeUuid From: David Howells <dhowells(a)redhat.com> [ Upstream commit f4b3526d83c40dd8bf5948b9d7a1b2c340f0dcc8 ] The handler for the CB.ProbeUuid operation in the cache manager is implemented, but isn't listed in the switch-statement of operation selection, so won't be used. Fix this by adding it. 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/cmservice.c | 3 +++ 1 file changed, 3 insertions(+) --- a/fs/afs/cmservice.c +++ b/fs/afs/cmservice.c @@ -127,6 +127,9 @@ bool afs_cm_incoming_call(struct afs_cal case CBProbe: call->type = &afs_SRXCBProbe; return true; + case CBProbeUuid: + call->type = &afs_SRXCBProbeUuid; + return true; case CBTellMeAboutYourself: call->type = &afs_SRXCBTellMeAboutYourself; return true; Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-4.14/x.509-reject-invalid-bit-string-for-subjectpublickey.patch queue-4.14/asn.1-check-for-error-from-asn1_op_end__act-actions.patch queue-4.14/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.14/afs-fix-total-length-calculation-for-multiple-page-send.patch queue-4.14/afs-connect-up-the-cb.probeuuid.patch queue-4.14/asn.1-fix-out-of-bounds-read-when-parsing-indefinite-length-item.patch queue-4.14/keys-reject-null-restriction-string-when-type-is-specified.patch queue-4.14/x.509-fix-comparisons-of-pkey_algo.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "efi/esrt: Use memunmap() instead of kfree() to free the remapping" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled efi/esrt: Use memunmap() instead of kfree() to free the remapping to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: efi-esrt-use-memunmap-instead-of-kfree-to-free-the-remapping.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 89c5a2d34bda58319e3075e8e7dd727ea25a435c Mon Sep 17 00:00:00 2001 From: Pan Bian <bianpan2016(a)163.com> Date: Wed, 6 Dec 2017 09:50:09 +0000 Subject: efi/esrt: Use memunmap() instead of kfree() to free the remapping From: Pan Bian <bianpan2016(a)163.com> commit 89c5a2d34bda58319e3075e8e7dd727ea25a435c upstream. The remapping result of memremap() should be freed with memunmap(), not kfree(). Signed-off-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Matt Fleming <matt(a)codeblueprint.co.uk> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-efi(a)vger.kernel.org Link: http://lkml.kernel.org/r/20171206095010.24170-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/firmware/efi/esrt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/firmware/efi/esrt.c +++ b/drivers/firmware/efi/esrt.c @@ -442,7 +442,7 @@ err_remove_group: err_remove_esrt: kobject_put(esrt_kobj); err: - kfree(esrt); + memunmap(esrt); esrt = NULL; return error; } Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.4/efi-esrt-use-memunmap-instead-of-kfree-to-free-the-remapping.patch

7 years, 9 months

3
2
0 0

[Linux-stable-mirror] WTF: patch "[PATCH] iio: fix kernel-doc build errors" was seriously submitted to be applied to the 4.14-stable tree?

by gregkh＠linuxfoundation.org

The patch below was submitted to be applied to the 4.14-stable tree. I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst. I could be totally wrong, and if so, please respond to <stable(a)vger.kernel.org> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From c175cb7cd953782bbf4e8bdf088ad61440d6dde5 Mon Sep 17 00:00:00 2001 From: Randy Dunlap <rdunlap(a)infradead.org> Date: Sun, 29 Oct 2017 17:06:01 -0700 Subject: [PATCH] iio: fix kernel-doc build errors Fix build errors in kernel-doc notation. Symbols that end in '_' have a special meaning, but adding a '*' makes them OK. ../drivers/iio/industrialio-core.c:635: ERROR: Unknown target name: "iio_val". ../drivers/iio/industrialio-core.c:642: ERROR: Unknown target name: "iio_val". Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index 9c4cfd19b739..2f0998ebeed2 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -631,7 +631,7 @@ static ssize_t __iio_format_value(char *buf, size_t len, unsigned int type, * iio_format_value() - Formats a IIO value into its string representation * @buf: The buffer to which the formatted value gets written * which is assumed to be big enough (i.e. PAGE_SIZE). - * @type: One of the IIO_VAL_... constants. This decides how the val + * @type: One of the IIO_VAL_* constants. This decides how the val * and val2 parameters are formatted. * @size: Number of IIO value entries contained in vals * @vals: Pointer to the values, exact meaning depends on the @@ -639,7 +639,7 @@ static ssize_t __iio_format_value(char *buf, size_t len, unsigned int type, * * Return: 0 by default, a negative number on failure or the * total number of characters written for a type that belongs - * to the IIO_VAL_... constant. + * to the IIO_VAL_* constant. */ ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals) {

7 years, 9 months

4
6
0 0

[Linux-stable-mirror] Patch "usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT" 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 usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT 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: usb-f_fs-force-reserved1-1-in-os_desc_ext_compat.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 a3acc696085e112733d191a77b106e67a4fa110b Mon Sep 17 00:00:00 2001 From: John Keeping <john(a)metanate.com> Date: Mon, 27 Nov 2017 18:15:40 +0000 Subject: usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT From: John Keeping <john(a)metanate.com> commit a3acc696085e112733d191a77b106e67a4fa110b upstream. The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT must have the value "1", but when this feature was first implemented we rejected any non-zero values. This was adjusted to accept all non-zero values (while now rejecting zero) in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace programs that worked previously by returning EINVAL when Reserved1 == 0 which was previously the only value that succeeded! If we just set the field to "1" ourselves, both old and new userspace programs continue to work correctly and, as a bonus, old programs are now compliant with the specification without having to fix anything themselves. Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT") Signed-off-by: John Keeping <john(a)metanate.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/function/f_fs.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -2262,9 +2262,18 @@ static int __ffs_data_do_os_desc(enum ff int i; if (len < sizeof(*d) || - d->bFirstInterfaceNumber >= ffs->interfaces_count || - d->Reserved1) + d->bFirstInterfaceNumber >= ffs->interfaces_count) return -EINVAL; + if (d->Reserved1 != 1) { + /* + * According to the spec, Reserved1 must be set to 1 + * but older kernels incorrectly rejected non-zero + * values. We fix it here to avoid returning EINVAL + * in response to values we used to accept. + */ + pr_debug("usb_ext_compat_desc::Reserved1 forced to 1\n"); + d->Reserved1 = 1; + } for (i = 0; i < ARRAY_SIZE(d->Reserved2); ++i) if (d->Reserved2[i]) return -EINVAL; Patches currently in stable-queue which might be from john(a)metanate.com are queue-4.9/usb-f_fs-force-reserved1-1-in-os_desc_ext_compat.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "thp: reduce indentation level in change_huge_pmd()" 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 thp: reduce indentation level in change_huge_pmd() 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: thp-reduce-indentation-level-in-change_huge_pmd.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 0a85e51d37645e9ce57e5e1a30859e07810ed07c Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Thu, 13 Apr 2017 14:56:17 -0700 Subject: thp: reduce indentation level in change_huge_pmd() From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> commit 0a85e51d37645e9ce57e5e1a30859e07810ed07c upstream. Patch series "thp: fix few MADV_DONTNEED races" For MADV_DONTNEED to work properly with huge pages, it's critical to not clear pmd intermittently unless you hold down_write(mmap_sem). Otherwise MADV_DONTNEED can miss the THP which can lead to userspace breakage. See example of such race in commit message of patch 2/4. All these races are found by code inspection. I haven't seen them triggered. I don't think it's worth to apply them to stable@. This patch (of 4): Restructure code in preparation for a fix. Link: http://lkml.kernel.org/r/20170302151034.27829-2-kirill.shutemov@linux.intel… Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Hillf Danton <hillf.zj(a)alibaba-inc.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> [jwang: adjust context for 4.9] Signed-off-by: Jack Wang <jinpu.wang(a)profitbricks.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/huge_memory.c | 56 +++++++++++++++++++++++++++---------------------------- 1 file changed, 28 insertions(+), 28 deletions(-) --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1509,37 +1509,37 @@ int change_huge_pmd(struct vm_area_struc { struct mm_struct *mm = vma->vm_mm; spinlock_t *ptl; - int ret = 0; + pmd_t entry; + bool preserve_write; + int ret; ptl = __pmd_trans_huge_lock(pmd, vma); - if (ptl) { - pmd_t entry; - bool preserve_write = prot_numa && pmd_write(*pmd); - ret = 1; - - /* - * Avoid trapping faults against the zero page. The read-only - * data is likely to be read-cached on the local CPU and - * local/remote hits to the zero page are not interesting. - */ - if (prot_numa && is_huge_zero_pmd(*pmd)) { - spin_unlock(ptl); - return ret; - } - - if (!prot_numa || !pmd_protnone(*pmd)) { - entry = pmdp_huge_get_and_clear_notify(mm, addr, pmd); - entry = pmd_modify(entry, newprot); - if (preserve_write) - entry = pmd_mkwrite(entry); - ret = HPAGE_PMD_NR; - set_pmd_at(mm, addr, pmd, entry); - BUG_ON(vma_is_anonymous(vma) && !preserve_write && - pmd_write(entry)); - } - spin_unlock(ptl); - } + if (!ptl) + return 0; + preserve_write = prot_numa && pmd_write(*pmd); + ret = 1; + + /* + * Avoid trapping faults against the zero page. The read-only + * data is likely to be read-cached on the local CPU and + * local/remote hits to the zero page are not interesting. + */ + if (prot_numa && is_huge_zero_pmd(*pmd)) + goto unlock; + + if (prot_numa && pmd_protnone(*pmd)) + goto unlock; + + entry = pmdp_huge_get_and_clear_notify(mm, addr, pmd); + entry = pmd_modify(entry, newprot); + if (preserve_write) + entry = pmd_mkwrite(entry); + ret = HPAGE_PMD_NR; + set_pmd_at(mm, addr, pmd, entry); + BUG_ON(vma_is_anonymous(vma) && !preserve_write && pmd_write(entry)); +unlock: + spin_unlock(ptl); return ret; } Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-4.9/mm-drop-unused-pmdp_huge_get_and_clear_notify.patch queue-4.9/thp-fix-madv_dontneed-vs.-numa-balancing-race.patch queue-4.9/thp-reduce-indentation-level-in-change_huge_pmd.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "thp: fix MADV_DONTNEED vs. numa balancing race" 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 thp: fix MADV_DONTNEED vs. numa balancing race 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: thp-fix-madv_dontneed-vs.-numa-balancing-race.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 ced108037c2aa542b3ed8b7afd1576064ad1362a Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Thu, 13 Apr 2017 14:56:20 -0700 Subject: thp: fix MADV_DONTNEED vs. numa balancing race From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> commit ced108037c2aa542b3ed8b7afd1576064ad1362a upstream. In case prot_numa, we are under down_read(mmap_sem). It's critical to not clear pmd intermittently to avoid race with MADV_DONTNEED which is also under down_read(mmap_sem): CPU0: CPU1: change_huge_pmd(prot_numa=1) pmdp_huge_get_and_clear_notify() madvise_dontneed() zap_pmd_range() pmd_trans_huge(*pmd) == 0 (without ptl) // skip the pmd set_pmd_at(); // pmd is re-established The race makes MADV_DONTNEED miss the huge pmd and don't clear it which may break userspace. Found by code analysis, never saw triggered. Link: http://lkml.kernel.org/r/20170302151034.27829-3-kirill.shutemov@linux.intel… Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Hillf Danton <hillf.zj(a)alibaba-inc.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> [jwang: adjust context for 4.9 ] Signed-off-by: Jack Wang <jinpu.wang(a)profitbricks.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/huge_memory.c | 34 +++++++++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1531,7 +1531,39 @@ int change_huge_pmd(struct vm_area_struc if (prot_numa && pmd_protnone(*pmd)) goto unlock; - entry = pmdp_huge_get_and_clear_notify(mm, addr, pmd); + /* + * In case prot_numa, we are under down_read(mmap_sem). It's critical + * to not clear pmd intermittently to avoid race with MADV_DONTNEED + * which is also under down_read(mmap_sem): + * + * CPU0: CPU1: + * change_huge_pmd(prot_numa=1) + * pmdp_huge_get_and_clear_notify() + * madvise_dontneed() + * zap_pmd_range() + * pmd_trans_huge(*pmd) == 0 (without ptl) + * // skip the pmd + * set_pmd_at(); + * // pmd is re-established + * + * The race makes MADV_DONTNEED miss the huge pmd and don't clear it + * which may break userspace. + * + * pmdp_invalidate() is required to make sure we don't miss + * dirty/young flags set by hardware. + */ + entry = *pmd; + pmdp_invalidate(vma, addr, pmd); + + /* + * Recover dirty/young flags. It relies on pmdp_invalidate to not + * corrupt them. + */ + if (pmd_dirty(*pmd)) + entry = pmd_mkdirty(entry); + if (pmd_young(*pmd)) + entry = pmd_mkyoung(entry); + entry = pmd_modify(entry, newprot); if (preserve_write) entry = pmd_mkwrite(entry); Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-4.9/mm-drop-unused-pmdp_huge_get_and_clear_notify.patch queue-4.9/thp-fix-madv_dontneed-vs.-numa-balancing-race.patch queue-4.9/thp-reduce-indentation-level-in-change_huge_pmd.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "mm: drop unused pmdp_huge_get_and_clear_notify()" 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 mm: drop unused pmdp_huge_get_and_clear_notify() 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: mm-drop-unused-pmdp_huge_get_and_clear_notify.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 c0c379e2931b05facef538e53bf3b21f283d9a0b Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Thu, 13 Apr 2017 14:56:23 -0700 Subject: mm: drop unused pmdp_huge_get_and_clear_notify() From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> commit c0c379e2931b05facef538e53bf3b21f283d9a0b upstream. Dave noticed that after fixing MADV_DONTNEED vs numa balancing race the last pmdp_huge_get_and_clear_notify() user is gone. Let's drop the helper. Link: http://lkml.kernel.org/r/20170306112047.24809-1-kirill.shutemov@linux.intel… Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> [jwang: adjust context for 4.9] Signed-off-by: Jack Wang <jinpu.wang(a)profitbricks.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/mmu_notifier.h | 13 ------------- 1 file changed, 13 deletions(-) --- a/include/linux/mmu_notifier.h +++ b/include/linux/mmu_notifier.h @@ -381,18 +381,6 @@ static inline void mmu_notifier_mm_destr ___pmd; \ }) -#define pmdp_huge_get_and_clear_notify(__mm, __haddr, __pmd) \ -({ \ - unsigned long ___haddr = __haddr & HPAGE_PMD_MASK; \ - pmd_t ___pmd; \ - \ - ___pmd = pmdp_huge_get_and_clear(__mm, __haddr, __pmd); \ - mmu_notifier_invalidate_range(__mm, ___haddr, \ - ___haddr + HPAGE_PMD_SIZE); \ - \ - ___pmd; \ -}) - /* * set_pte_at_notify() sets the pte _after_ running the notifier. * This is safe to start by updating the secondary MMUs, because the primary MMU @@ -480,7 +468,6 @@ static inline void mmu_notifier_mm_destr #define pmdp_clear_young_notify pmdp_test_and_clear_young #define ptep_clear_flush_notify ptep_clear_flush #define pmdp_huge_clear_flush_notify pmdp_huge_clear_flush -#define pmdp_huge_get_and_clear_notify pmdp_huge_get_and_clear #define set_pte_at_notify set_pte_at #endif /* CONFIG_MMU_NOTIFIER */ Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-4.9/mm-drop-unused-pmdp_huge_get_and_clear_notify.patch queue-4.9/thp-fix-madv_dontneed-vs.-numa-balancing-race.patch queue-4.9/thp-reduce-indentation-level-in-change_huge_pmd.patch

7 years, 9 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: talitos - fix use of sg_link_tbl_len" 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: talitos - fix use of sg_link_tbl_len 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-talitos-fix-use-of-sg_link_tbl_len.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 fbb22137c4d9bab536958b152d096fb3f98020ea Mon Sep 17 00:00:00 2001 From: LEROY Christophe <christophe.leroy(a)c-s.fr> Date: Fri, 6 Oct 2017 15:04:41 +0200 Subject: crypto: talitos - fix use of sg_link_tbl_len From: LEROY Christophe <christophe.leroy(a)c-s.fr> commit fbb22137c4d9bab536958b152d096fb3f98020ea upstream. sg_link_tbl_len shall be used instead of cryptlen, otherwise SECs which perform HW CICV verification will fail. Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/talitos.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -1232,8 +1232,8 @@ static int ipsec_esp(struct talitos_edes sg_link_tbl_len += authsize; } - ret = talitos_sg_map(dev, areq->src, cryptlen, edesc, &desc->ptr[4], - sg_count, areq->assoclen, tbl_off); + ret = talitos_sg_map(dev, areq->src, sg_link_tbl_len, edesc, + &desc->ptr[4], sg_count, areq->assoclen, tbl_off); if (ret > 1) { tbl_off += ret; Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are queue-4.9/crypto-talitos-fix-aead-for-sha224-on-non-sha224-capable-chips.patch queue-4.9/crypto-talitos-fix-memory-corruption-on-sec2.patch queue-4.9/crypto-talitos-fix-use-of-sg_link_tbl_len.patch queue-4.9/crypto-talitos-fix-setkey-to-check-key-weakness.patch queue-4.9/crypto-talitos-fix-aead-test-failures.patch queue-4.9/crypto-talitos-fix-ctr-aes-talitos.patch

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror