This is a note to let you know that I've just added the patch titled
drivers/rapidio/devices/rio_mport_cdev.c: fix resource leak in error handling path in 'rio_dma_transfer()'
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:
drivers-rapidio-devices-rio_mport_cdev.c-fix-resource-leak-in-error-handling-path-in-rio_dma_transfer.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: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Fri, 17 Nov 2017 15:37:57 -0800
Subject: drivers/rapidio/devices/rio_mport_cdev.c: fix resource leak in error handling path in 'rio_dma_transfer()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit b1402dcb5643b7a27d46a05edd7491d49ba0e248 ]
If 'dma_map_sg()', we should branch to the existing error handling path
to free some resources before returning.
Link: http://lkml.kernel.org/r/61292a4f369229eee03394247385e955027283f8.150568704…
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com>
Cc: Matt Porter <mporter(a)kernel.crashing.org>
Cc: Alexandre Bounine <alexandre.bounine(a)idt.com>
Cc: Lorenzo Stoakes <lstoakes(a)gmail.com>
Cc: Jesper Nilsson <jesper.nilsson(a)axis.com>
Cc: Christian K_nig <christian.koenig(a)amd.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rapidio/devices/rio_mport_cdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -963,7 +963,8 @@ rio_dma_transfer(struct file *filp, u32
req->sgt.sgl, req->sgt.nents, dir);
if (nents == -EFAULT) {
rmcd_error("Failed to map SG list");
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_pg;
}
ret = do_dma_request(req, xfer, sync, nents);
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/bus-arm-ccn-check-memory-allocation-failure.patch
queue-4.14/drivers-rapidio-devices-rio_mport_cdev.c-fix-resource-leak-in-error-handling-path-in-rio_dma_transfer.patch
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
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
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
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
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
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
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
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
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