This is a note to let you know that I've just added the patch titled
spi: sh-msiof: Fix DMA transfer size check
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:
spi-sh-msiof-fix-dma-transfer-size-check.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 Wed Dec 6 18:04:41 CET 2017
From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Date: Thu, 2 Nov 2017 10:32:36 +0100
Subject: spi: sh-msiof: Fix DMA transfer size check
From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support")
Signed-off-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Dirk Behme <dirk.behme(a)de.bosch.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-sh-msiof.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -900,7 +900,7 @@ static int sh_msiof_transfer_one(struct
break;
copy32 = copy_bswap32;
} else if (bits <= 16) {
- if (l & 1)
+ if (l & 3)
break;
copy32 = copy_wswap32;
} else {
Patches currently in stable-queue which might be from hiromitsu.yamasaki.ym(a)renesas.com are
queue-4.14/spi-sh-msiof-fix-dma-transfer-size-check.patch
This is a note to let you know that I've just added the patch titled
serial: sh-sci: suppress warning for ports without dma channels
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:
serial-sh-sci-suppress-warning-for-ports-without-dma-channels.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 Wed Dec 6 18:04:41 CET 2017
From: Andy Lowe <andy_lowe(a)mentor.com>
Date: Fri, 22 Sep 2017 20:29:30 +0200
Subject: serial: sh-sci: suppress warning for ports without dma channels
From: Andy Lowe <andy_lowe(a)mentor.com>
[ Upstream commit 7464779fa8551b90d5797d4020b0bdb7e6422eb9 ]
If a port has no dma channel defined in the device tree, then
don't attempt to allocate a dma channel for the port.
Also suppress the warning message concerning the failure to allocate
a dma channel. Continue to emit the warning message if a dma
channel is defined but cannot be allocated.
Signed-off-by: Andy Lowe <andy_lowe(a)mentor.com>
Signed-off-by: Eugeniu Rosca <erosca(a)de.adit-jv.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1491,6 +1491,14 @@ static void sci_request_dma(struct uart_
return;
s->cookie_tx = -EINVAL;
+
+ /*
+ * Don't request a dma channel if no channel was specified
+ * in the device tree.
+ */
+ if (!of_find_property(port->dev->of_node, "dmas", NULL))
+ return;
+
chan = sci_request_dma_chan(port, DMA_MEM_TO_DEV);
dev_dbg(port->dev, "%s: TX: got channel %p\n", __func__, chan);
if (chan) {
Patches currently in stable-queue which might be from andy_lowe(a)mentor.com are
queue-4.14/serial-sh-sci-suppress-warning-for-ports-without-dma-channels.patch
This is a note to let you know that I've just added the patch titled
serial: imx: Update cached mctrl value when changing RTS
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:
serial-imx-update-cached-mctrl-value-when-changing-rts.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 Wed Dec 6 18:04:41 CET 2017
From: Ian Jamison <ian.dev(a)arkver.com>
Date: Thu, 21 Sep 2017 10:13:12 +0200
Subject: serial: imx: Update cached mctrl value when changing RTS
From: Ian Jamison <ian.dev(a)arkver.com>
[ Upstream commit a0983c742a5885f82afb282166f83f1d3d8addf4 ]
UART core function uart_update_mctrl relies on a cached value of
modem control lines. This was used but not updated by local RTS
control functions within imx.c. These are used for RS485 line
driver enable signalling. Having an out-of-date value in the cached
mctrl can result in the transmitter being enabled when it shouldn't
be.
Fix this by updating the mctrl value before applying it.
Signed-off-by: Ian Jamison <ian.dev(a)arkver.com>
Origin: id:8195c96e674517b82a6ff7fe914c7ba0f86e702b.1505375165.git.ian.dev@arkver.com
Acked-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Tested-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Tested-by: Clemens Gruber <clemens.gruber(a)pqgruber.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/imx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -334,7 +334,8 @@ static void imx_port_rts_active(struct i
{
*ucr2 &= ~(UCR2_CTSC | UCR2_CTS);
- mctrl_gpio_set(sport->gpios, sport->port.mctrl | TIOCM_RTS);
+ sport->port.mctrl |= TIOCM_RTS;
+ mctrl_gpio_set(sport->gpios, sport->port.mctrl);
}
static void imx_port_rts_inactive(struct imx_port *sport, unsigned long *ucr2)
@@ -342,7 +343,8 @@ static void imx_port_rts_inactive(struct
*ucr2 &= ~UCR2_CTSC;
*ucr2 |= UCR2_CTS;
- mctrl_gpio_set(sport->gpios, sport->port.mctrl & ~TIOCM_RTS);
+ sport->port.mctrl &= ~TIOCM_RTS;
+ mctrl_gpio_set(sport->gpios, sport->port.mctrl);
}
static void imx_port_rts_auto(struct imx_port *sport, unsigned long *ucr2)
Patches currently in stable-queue which might be from ian.dev(a)arkver.com are
queue-4.14/serial-imx-update-cached-mctrl-value-when-changing-rts.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
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:
serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.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 Wed Dec 6 18:04:41 CET 2017
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sat, 28 Oct 2017 11:35:49 +0200
Subject: serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
From: Lukas Wunner <lukas(a)wunner.de>
[ Upstream commit 3236a965486ba0c6043cf2c7b51943d8b382ae29 ]
This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND
and SER_RS485_RTS_AFTER_SEND have the same value. If they do, it means
the user has passed in invalid data with the TIOCSRS485 ioctl()
since RTS must have a different polarity when sending and when not
sending. In this case, rs485 mode is not enabled (the RS485_URA bit
is not set in the RS485 Enable Register) and this is supposed to be
signaled back to the user by clearing the SER_RS485_ENABLED bit in
struct serial_rs485 ... except a missing tilde character is preventing
that from happening.
Fixes: 28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART")
Cc: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Cc: "Ji-Ze Hong (Peter Hong)" <hpeter(a)gmail.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_fintek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/8250/8250_fintek.c
+++ b/drivers/tty/serial/8250/8250_fintek.c
@@ -211,7 +211,7 @@ static int fintek_8250_rs485_config(stru
if ((!!(rs485->flags & SER_RS485_RTS_ON_SEND)) ==
(!!(rs485->flags & SER_RS485_RTS_AFTER_SEND)))
- rs485->flags &= SER_RS485_ENABLED;
+ rs485->flags &= ~SER_RS485_ENABLED;
else
config |= RS485_URA;
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.14/serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch
This is a note to let you know that I've just added the patch titled
serial: 8250: Preserve DLD[7:4] for PORT_XR17V35X
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:
serial-8250-preserve-dld-for-port_xr17v35x.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 Wed Dec 6 18:04:41 CET 2017
From: Aaron Sierra <asierra(a)xes-inc.com>
Date: Wed, 4 Oct 2017 10:01:28 -0500
Subject: serial: 8250: Preserve DLD[7:4] for PORT_XR17V35X
From: Aaron Sierra <asierra(a)xes-inc.com>
[ Upstream commit 0ab84da2e076948c49d36197ee7d254125c53eab ]
The upper four bits of the XR17V35x fractional divisor register (DLD)
control general chip function (RS-485 direction pin polarity, multidrop
mode, XON/XOFF parity check, and fast IR mode). Don't allow these bits
to be clobbered when setting the baudrate.
Signed-off-by: Aaron Sierra <asierra(a)xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2586,8 +2586,11 @@ static void serial8250_set_divisor(struc
serial_dl_write(up, quot);
/* XR17V35x UARTs have an extra fractional divisor register (DLD) */
- if (up->port.type == PORT_XR17V35X)
+ if (up->port.type == PORT_XR17V35X) {
+ /* Preserve bits not related to baudrate; DLD[7:4]. */
+ quot_frac |= serial_port_in(port, 0x2) & 0xf0;
serial_port_out(port, 0x2, quot_frac);
+ }
}
static unsigned int serial8250_get_baud_rate(struct uart_port *port,
Patches currently in stable-queue which might be from asierra(a)xes-inc.com are
queue-4.14/serial-8250-preserve-dld-for-port_xr17v35x.patch
This is a note to let you know that I've just added the patch titled
selftests/x86/ldt_get: Add a few additional tests for limits
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:
selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.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 Wed Dec 6 18:04:41 CET 2017
From: Andy Lutomirski <luto(a)kernel.org>
Date: Sat, 4 Nov 2017 04:19:52 -0700
Subject: selftests/x86/ldt_get: Add a few additional tests for limits
From: Andy Lutomirski <luto(a)kernel.org>
[ Upstream commit fec8f5ae1715a01c72ad52cb2ecd8aacaf142302 ]
We weren't testing the .limit and .limit_in_pages fields very well.
Add more tests.
This addition seems to trigger the "bits 16:19 are undefined" issue
that was fixed in an earlier patch. I think that, at least on my
CPU, the high nibble of the limit ends in LAR bits 16:19.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bpetkov(a)suse.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/5601c15ea9b3113d288953fd2838b18bedf6bc67.150979432…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/x86/ldt_gdt.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
--- a/tools/testing/selftests/x86/ldt_gdt.c
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -367,9 +367,24 @@ static void do_simple_tests(void)
install_invalid(&desc, false);
desc.seg_not_present = 0;
- desc.read_exec_only = 0;
desc.seg_32bit = 1;
+ desc.read_exec_only = 0;
+ desc.limit = 0xfffff;
+
install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA | AR_S | AR_P | AR_DB);
+
+ desc.limit_in_pages = 1;
+
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA | AR_S | AR_P | AR_DB | AR_G);
+ desc.read_exec_only = 1;
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RODATA | AR_S | AR_P | AR_DB | AR_G);
+ desc.contents = 1;
+ desc.read_exec_only = 0;
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA_EXPDOWN | AR_S | AR_P | AR_DB | AR_G);
+ desc.read_exec_only = 1;
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RODATA_EXPDOWN | AR_S | AR_P | AR_DB | AR_G);
+
+ desc.limit = 0;
install_invalid(&desc, true);
}
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.14/selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.patch
queue-4.14/selftests-x86-ldt_gdt-robustify-against-set_thread_area-and-lar-oddities.patch
queue-4.14/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
This is a note to let you know that I've just added the patch titled
selftests/x86/ldt_gdt: Robustify against set_thread_area() and LAR oddities
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:
selftests-x86-ldt_gdt-robustify-against-set_thread_area-and-lar-oddities.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 Wed Dec 6 18:04:41 CET 2017
From: Andy Lutomirski <luto(a)kernel.org>
Date: Sat, 4 Nov 2017 04:19:49 -0700
Subject: selftests/x86/ldt_gdt: Robustify against set_thread_area() and LAR oddities
From: Andy Lutomirski <luto(a)kernel.org>
[ Upstream commit d60ad744c9741586010d4bea286f09a063a90fbd ]
Bits 19:16 of LAR's result are undefined, and some upcoming
improvements to the test case seem to trigger this. Mask off those
bits to avoid spurious failures.
commit 5b781c7e317f ("x86/tls: Forcibly set the accessed bit in TLS
segments") adds a valid case in which LAR's output doesn't quite
agree with set_thread_area()'s input. This isn't triggered in the
test as is, but it will be if we start calling set_thread_area()
with the accessed bit clear. Work around this discrepency.
I've added a Fixes tag so that -stable can pick this up if neccesary.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bpetkov(a)suse.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Fixes: 5b781c7e317f ("x86/tls: Forcibly set the accessed bit in TLS segments")
Link: http://lkml.kernel.org/r/b82f3f89c034b53580970ac865139fd8863f44e2.150979432…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/x86/ldt_gdt.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/tools/testing/selftests/x86/ldt_gdt.c
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -115,7 +115,15 @@ static void check_valid_segment(uint16_t
return;
}
- if (ar != expected_ar) {
+ /* The SDM says "bits 19:16 are undefined". Thanks. */
+ ar &= ~0xF0000;
+
+ /*
+ * NB: Different Linux versions do different things with the
+ * accessed bit in set_thread_area().
+ */
+ if (ar != expected_ar &&
+ (ldt || ar != (expected_ar | AR_ACCESSED))) {
printf("[FAIL]\t%s entry %hu has AR 0x%08X but expected 0x%08X\n",
(ldt ? "LDT" : "GDT"), index, ar, expected_ar);
nerrs++;
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.14/selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.patch
queue-4.14/selftests-x86-ldt_gdt-robustify-against-set_thread_area-and-lar-oddities.patch
queue-4.14/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
This is a note to let you know that I've just added the patch titled
s390: vfio-ccw: Do not attempt to free no-op, test and tic cda.
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:
s390-vfio-ccw-do-not-attempt-to-free-no-op-test-and-tic-cda.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 Wed Dec 6 18:04:41 CET 2017
From: "Jason J. Herne" <jjherne(a)linux.vnet.ibm.com>
Date: Tue, 7 Nov 2017 10:22:32 -0500
Subject: s390: vfio-ccw: Do not attempt to free no-op, test and tic cda.
From: "Jason J. Herne" <jjherne(a)linux.vnet.ibm.com>
[ Upstream commit 408358b50deaf59b07c82a7bff8c7e7cce031fae ]
Because we do not make use of the cda (channel data address) for test,
no-op ccws no address translation takes place. This means cda could
contain a guest address which we do not want to attempt to free. Let's
check the command type and skip cda free when it is not needed.
For a TIC ccw, ccw->cda points to either a ccw in an existing chain or
it points to a whole new allocated chain. In either case the data will
be freed when the owning chain is freed.
Signed-off-by: Jason J. Herne <jjherne(a)linux.vnet.ibm.com>
Reviewed-by: Dong Jia Shi <bjsdjshi(a)linux.vnet.ibm.com>
Reviewed-by: Pierre Morel <pmorel(a)linux.vnet.ibm.com>
Message-Id: <1510068152-21988-1-git-send-email-jjherne(a)linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic(a)linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/cio/vfio_ccw_cp.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/s390/cio/vfio_ccw_cp.c
+++ b/drivers/s390/cio/vfio_ccw_cp.c
@@ -330,6 +330,8 @@ static void ccwchain_cda_free(struct ccw
{
struct ccw1 *ccw = chain->ch_ccw + idx;
+ if (ccw_is_test(ccw) || ccw_is_noop(ccw) || ccw_is_tic(ccw))
+ return;
if (!ccw->count)
return;
Patches currently in stable-queue which might be from jjherne(a)linux.vnet.ibm.com are
queue-4.14/s390-vfio-ccw-do-not-attempt-to-free-no-op-test-and-tic-cda.patch
This is a note to let you know that I've just added the patch titled
s390/ptrace: fix guarded storage regset handling
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:
s390-ptrace-fix-guarded-storage-regset-handling.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 Wed Dec 6 18:04:41 CET 2017
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Date: Mon, 11 Sep 2017 11:24:23 +0200
Subject: s390/ptrace: fix guarded storage regset handling
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
[ Upstream commit 5ef2d5231d547c672c67bdf84c13a4adaf477964 ]
If the guarded storage regset for current is supposed to be changed,
the regset from user space is copied directly into the guarded storage
control block.
If then the process gets scheduled away while the control block is
being copied and before the new control block has been loaded, the
result is random: the process can be scheduled away due to a page
fault or preemption. If that happens the already copied parts will be
overwritten by save_gs_cb(), called from switch_to().
Avoid this by copying the data to a temporary buffer on the stack and
do the actual update with preemption disabled.
Fixes: f5bbd7219891 ("s390/ptrace: guarded storage regset for the current task")
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/kernel/ptrace.c | 33 ++++++++++++++++++++++-----------
1 file changed, 22 insertions(+), 11 deletions(-)
--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -1172,26 +1172,37 @@ static int s390_gs_cb_set(struct task_st
unsigned int pos, unsigned int count,
const void *kbuf, const void __user *ubuf)
{
- struct gs_cb *data = target->thread.gs_cb;
+ struct gs_cb gs_cb = { }, *data = NULL;
int rc;
if (!MACHINE_HAS_GS)
return -ENODEV;
- if (!data) {
+ if (!target->thread.gs_cb) {
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
- data->gsd = 25;
- target->thread.gs_cb = data;
- if (target == current)
- __ctl_set_bit(2, 4);
- } else if (target == current) {
- save_gs_cb(data);
}
+ if (!target->thread.gs_cb)
+ gs_cb.gsd = 25;
+ else if (target == current)
+ save_gs_cb(&gs_cb);
+ else
+ gs_cb = *target->thread.gs_cb;
rc = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
- data, 0, sizeof(struct gs_cb));
- if (target == current)
- restore_gs_cb(data);
+ &gs_cb, 0, sizeof(gs_cb));
+ if (rc) {
+ kfree(data);
+ return -EFAULT;
+ }
+ preempt_disable();
+ if (!target->thread.gs_cb)
+ target->thread.gs_cb = data;
+ *target->thread.gs_cb = gs_cb;
+ if (target == current) {
+ __ctl_set_bit(2, 4);
+ restore_gs_cb(target->thread.gs_cb);
+ }
+ preempt_enable();
return rc;
}
Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are
queue-4.14/s390-ptrace-fix-guarded-storage-regset-handling.patch
queue-4.14/s390-pci-do-not-require-ais-facility.patch
queue-4.14/perf-test-attr-fix-ignored-test-case-result.patch
queue-4.14/s390-runtime-instrumentation-simplify-task-exit-handling.patch
queue-4.14/perf-test-attr-fix-python-error-on-empty-result.patch
This is a note to let you know that I've just added the patch titled
s390/pci: do not require AIS facility
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:
s390-pci-do-not-require-ais-facility.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 Wed Dec 6 18:04:41 CET 2017
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
Date: Mon, 30 Oct 2017 14:38:58 +0100
Subject: s390/pci: do not require AIS facility
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
[ Upstream commit 48070c73058be6de9c0d754d441ed7092dfc8f12 ]
As of today QEMU does not provide the AIS facility to its guest. This
prevents Linux guests from using PCI devices as the ais facility is
checked during init. As this is just a performance optimization, we can
move the ais check into the code where we need it (calling the SIC
instruction). This is used at initialization and on interrupt. Both
places do not require any serialization, so we can simply skip the
instruction.
Since we will now get all interrupts, we can also avoid the 2nd scan.
As we can have multiple interrupts in parallel we might trigger spurious
irqs more often for the non-AIS case but the core code can handle that.
Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Reviewed-by: Pierre Morel <pmorel(a)linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic(a)linux.vnet.ibm.com>
Acked-by: Sebastian Ott <sebott(a)linux.vnet.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/include/asm/pci_insn.h | 2 +-
arch/s390/pci/pci.c | 5 +++--
arch/s390/pci/pci_insn.c | 6 +++++-
3 files changed, 9 insertions(+), 4 deletions(-)
--- a/arch/s390/include/asm/pci_insn.h
+++ b/arch/s390/include/asm/pci_insn.h
@@ -82,6 +82,6 @@ int zpci_refresh_trans(u64 fn, u64 addr,
int zpci_load(u64 *data, u64 req, u64 offset);
int zpci_store(u64 data, u64 req, u64 offset);
int zpci_store_block(const u64 *data, u64 req, u64 offset);
-void zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc);
+int zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc);
#endif
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -368,7 +368,8 @@ static void zpci_irq_handler(struct airq
/* End of second scan with interrupts on. */
break;
/* First scan complete, reenable interrupts. */
- zpci_set_irq_ctrl(SIC_IRQ_MODE_SINGLE, NULL, PCI_ISC);
+ if (zpci_set_irq_ctrl(SIC_IRQ_MODE_SINGLE, NULL, PCI_ISC))
+ break;
si = 0;
continue;
}
@@ -956,7 +957,7 @@ static int __init pci_base_init(void)
if (!s390_pci_probe)
return 0;
- if (!test_facility(69) || !test_facility(71) || !test_facility(72))
+ if (!test_facility(69) || !test_facility(71))
return 0;
rc = zpci_debug_init();
--- a/arch/s390/pci/pci_insn.c
+++ b/arch/s390/pci/pci_insn.c
@@ -7,6 +7,7 @@
#include <linux/export.h>
#include <linux/errno.h>
#include <linux/delay.h>
+#include <asm/facility.h>
#include <asm/pci_insn.h>
#include <asm/pci_debug.h>
#include <asm/processor.h>
@@ -91,11 +92,14 @@ int zpci_refresh_trans(u64 fn, u64 addr,
}
/* Set Interruption Controls */
-void zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc)
+int zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc)
{
+ if (!test_facility(72))
+ return -EIO;
asm volatile (
" .insn rsy,0xeb00000000d1,%[ctl],%[isc],%[u]\n"
: : [ctl] "d" (ctl), [isc] "d" (isc << 27), [u] "Q" (*unused));
+ return 0;
}
/* PCI Load */
Patches currently in stable-queue which might be from borntraeger(a)de.ibm.com are
queue-4.14/s390-pci-do-not-require-ais-facility.patch
queue-4.14/s390-vfio-ccw-do-not-attempt-to-free-no-op-test-and-tic-cda.patch
This is a note to let you know that I've just added the patch titled
PM / Domains: Fix genpd to deal with drivers returning 1 from ->prepare()
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:
pm-domains-fix-genpd-to-deal-with-drivers-returning-1-from-prepare.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 Wed Dec 6 18:04:41 CET 2017
From: Ulf Hansson <ulf.hansson(a)linaro.org>
Date: Wed, 8 Nov 2017 10:11:02 +0100
Subject: PM / Domains: Fix genpd to deal with drivers returning 1 from ->prepare()
From: Ulf Hansson <ulf.hansson(a)linaro.org>
[ Upstream commit 5241ab40f6e742f8a1631f8826faf6dc6412b3b5 ]
During system-wide PM, genpd relies on its PM callbacks to be invoked for
all its attached devices, as to deal with powering off/on the PM domain. In
other words, genpd is not compatible with the direct_complete path, if
executed by the PM core for any of its attached devices.
However, when genpd's ->prepare() callback invokes pm_generic_prepare(), it
does not take into account that it may return 1. Instead it treats that as
an error internally and expects the PM core to abort the prepare phase and
roll back. This leads to genpd not properly powering on/off the PM domain,
because its internal counters gets wrongly balanced.
To fix the behaviour, allow drivers to return 1 from their ->prepare()
callbacks, but let's return 0 from genpd's ->prepare() callback in such
case, as that prevents the PM core from running the direct_complete path
for the device.
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/power/domain.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -921,7 +921,7 @@ static int pm_genpd_prepare(struct devic
genpd_unlock(genpd);
ret = pm_generic_prepare(dev);
- if (ret) {
+ if (ret < 0) {
genpd_lock(genpd);
genpd->prepared_count--;
@@ -929,7 +929,8 @@ static int pm_genpd_prepare(struct devic
genpd_unlock(genpd);
}
- return ret;
+ /* Never return 1, as genpd don't cope with the direct_complete path. */
+ return ret >= 0 ? 0 : ret;
}
/**
Patches currently in stable-queue which might be from ulf.hansson(a)linaro.org are
queue-4.14/mmc-tmio-check-mmc_regulator_get_supply-return-value.patch
queue-4.14/pm-domains-fix-genpd-to-deal-with-drivers-returning-1-from-prepare.patch
queue-4.14/mmc-sdhci-msm-fix-issue-with-power-irq.patch
This is a note to let you know that I've just added the patch titled
perf tools: Fix leaking rec_argv in error cases
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:
perf-tools-fix-leaking-rec_argv-in-error-cases.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 Wed Dec 6 18:04:41 CET 2017
From: Martin Kepplinger <martink(a)posteo.de>
Date: Wed, 13 Sep 2017 21:14:19 +0200
Subject: perf tools: Fix leaking rec_argv in error cases
From: Martin Kepplinger <martink(a)posteo.de>
[ Upstream commit c896f85a7c15ab9d040ffac8b8003e47996602a2 ]
Let's free the allocated rec_argv in case we return early, in order to
avoid leaking memory.
This adds free() at a few very similar places across the tree where it
was missing.
Signed-off-by: Martin Kepplinger <martink(a)posteo.de>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Martin kepplinger <martink(a)posteo.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Link: http://lkml.kernel.org/r/20170913191419.29806-1-martink@posteo.de
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/builtin-c2c.c | 1 +
tools/perf/builtin-mem.c | 1 +
tools/perf/builtin-timechart.c | 4 +++-
tools/perf/builtin-trace.c | 1 +
4 files changed, 6 insertions(+), 1 deletion(-)
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -2733,6 +2733,7 @@ static int perf_c2c__record(int argc, co
if (!perf_mem_events[j].supported) {
pr_err("failed: event '%s' not supported\n",
perf_mem_events[j].name);
+ free(rec_argv);
return -1;
}
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -113,6 +113,7 @@ static int __cmd_record(int argc, const
if (!perf_mem_events[j].supported) {
pr_err("failed: event '%s' not supported\n",
perf_mem_events__name(j));
+ free(rec_argv);
return -1;
}
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -1732,8 +1732,10 @@ static int timechart__io_record(int argc
if (rec_argv == NULL)
return -ENOMEM;
- if (asprintf(&filter, "common_pid != %d", getpid()) < 0)
+ if (asprintf(&filter, "common_pid != %d", getpid()) < 0) {
+ free(rec_argv);
return -ENOMEM;
+ }
p = rec_argv;
for (i = 0; i < common_args_nr; i++)
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2086,6 +2086,7 @@ static int trace__record(struct trace *t
rec_argv[j++] = "syscalls:sys_enter,syscalls:sys_exit";
else {
pr_err("Neither raw_syscalls nor syscalls events exist.\n");
+ free(rec_argv);
return -1;
}
}
Patches currently in stable-queue which might be from martink(a)posteo.de are
queue-4.14/perf-tools-fix-leaking-rec_argv-in-error-cases.patch
This is a note to let you know that I've just added the patch titled
perf test attr: Fix python error on empty result
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:
perf-test-attr-fix-python-error-on-empty-result.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 Wed Dec 6 18:04:41 CET 2017
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
Date: Wed, 13 Sep 2017 10:12:08 +0200
Subject: perf test attr: Fix python error on empty result
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
[ Upstream commit 3440fe2790aa3d13530260af6033533b18959aee ]
Commit d78ada4a767 ("perf tests attr: Do not store failed events") does
not create an event file in the /tmp directory when the
perf_open_event() system call failed.
This can lead to a situation where not /tmp/event-xx-yy-zz result file
exists at all (for example on a s390x virtual machine environment) where
no CPUMF hardware is available.
The following command then fails with a python call back chain instead
of printing failure:
[root@s8360046 perf]# /usr/bin/python2 ./tests/attr.py -d ./tests/attr/ \
-p ./perf -v -ttest-stat-basic
running './tests/attr//test-stat-basic'
Traceback (most recent call last):
File "./tests/attr.py", line 379, in <module>
main()
File "./tests/attr.py", line 370, in main
run_tests(options)
File "./tests/attr.py", line 311, in run_tests
Test(f, options).run()
File "./tests/attr.py", line 300, in run
self.compare(self.expect, self.result)
File "./tests/attr.py", line 248, in compare
exp_event.diff(res_event)
UnboundLocalError: local variable 'res_event' referenced before assignment
[root@s8360046 perf]#
This patch catches this pitfall and prints an error message instead:
[root@s8360047 perf]# /usr/bin/python2 ./tests/attr.py -d ./tests/attr/ \
-p ./perf -vvv -ttest-stat-basic
running './tests/attr//test-stat-basic'
loading expected events
Event event:base-stat
fd = 1
group_fd = -1
flags = 0|8
[....]
sample_regs_user = 0
sample_stack_user = 0
'PERF_TEST_ATTR=/tmp/tmpJbMQMP ./perf stat -o /tmp/tmpJbMQMP/perf.data -e cycles kill >/dev/null 2>&1' ret '1', expected '1'
loading result events
compare
matching [event:base-stat]
match: [event:base-stat] matches []
res_event is empty
FAILED './tests/attr//test-stat-basic' - match failure
[root@s8360047 perf]#
Signed-off-by: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Cc: Hendrik Brueckner <brueckner(a)linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Cc: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
LPU-Reference: 20170913081209.39570-1-tmricht(a)linux.vnet.ibm.com
Link: http://lkml.kernel.org/n/tip-04d63nn7svfgxdhi60gq2mlm@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/tests/attr.py | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/tools/perf/tests/attr.py
+++ b/tools/perf/tests/attr.py
@@ -238,6 +238,7 @@ class Test(object):
# events in result. Fail if there's not any.
for exp_name, exp_event in expect.items():
exp_list = []
+ res_event = {}
log.debug(" matching [%s]" % exp_name)
for res_name, res_event in result.items():
log.debug(" to [%s]" % res_name)
@@ -254,7 +255,10 @@ class Test(object):
if exp_event.optional():
log.debug(" %s does not match, but is optional" % exp_name)
else:
- exp_event.diff(res_event)
+ if not res_event:
+ log.debug(" res_event is empty");
+ else:
+ exp_event.diff(res_event)
raise Fail(self, 'match failure');
match[exp_name] = exp_list
Patches currently in stable-queue which might be from tmricht(a)linux.vnet.ibm.com are
queue-4.14/perf-test-attr-fix-ignored-test-case-result.patch
queue-4.14/perf-test-attr-fix-python-error-on-empty-result.patch
This is a note to let you know that I've just added the patch titled
perf test attr: Fix ignored test case result
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:
perf-test-attr-fix-ignored-test-case-result.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 Wed Dec 6 18:04:41 CET 2017
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
Date: Wed, 13 Sep 2017 10:12:09 +0200
Subject: perf test attr: Fix ignored test case result
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
[ Upstream commit 22905582f6dd4bbd0c370fe5732c607452010c04 ]
Command perf test -v 16 (Setup struct perf_event_attr test) always
reports success even if the test case fails. It works correctly if you
also specify -F (for don't fork).
root@s35lp76 perf]# ./perf test -v 16
15: Setup struct perf_event_attr :
--- start ---
running './tests/attr/test-record-no-delay'
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB /tmp/tmp4E1h7R/perf.data
(1 samples) ]
expected task=0, got 1
expected precise_ip=0, got 3
expected wakeup_events=1, got 0
FAILED './tests/attr/test-record-no-delay' - match failure
test child finished with 0
---- end ----
Setup struct perf_event_attr: Ok
The reason for the wrong error reporting is the return value of the
system() library call. It is called in run_dir() file tests/attr.c and
returns the exit status, in above case 0xff00.
This value is given as parameter to the exit() function which can only
handle values 0-0xff.
The child process terminates with exit value of 0 and the parent does
not detect any error.
This patch corrects the error reporting and prints the correct test
result.
Signed-off-by: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Cc: Hendrik Brueckner <brueckner(a)linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Cc: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
LPU-Reference: 20170913081209.39570-2-tmricht(a)linux.vnet.ibm.com
Link: http://lkml.kernel.org/n/tip-rdube6rfcjsr1nzue72c7lqn@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/tests/attr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -167,7 +167,7 @@ static int run_dir(const char *d, const
snprintf(cmd, 3*PATH_MAX, PYTHON " %s/attr.py -d %s/attr/ -p %s %.*s",
d, d, perf, vcnt, v);
- return system(cmd);
+ return system(cmd) ? TEST_FAIL : TEST_OK;
}
int test__attr(struct test *test __maybe_unused, int subtest __maybe_unused)
Patches currently in stable-queue which might be from tmricht(a)linux.vnet.ibm.com are
queue-4.14/perf-test-attr-fix-ignored-test-case-result.patch
queue-4.14/perf-test-attr-fix-python-error-on-empty-result.patch
This is a note to let you know that I've just added the patch titled
perf/core: Fix __perf_read_group_add() locking
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:
perf-core-fix-__perf_read_group_add-locking.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 Wed Dec 6 18:04:41 CET 2017
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Tue, 5 Sep 2017 13:38:24 +0200
Subject: perf/core: Fix __perf_read_group_add() locking
From: Peter Zijlstra <peterz(a)infradead.org>
[ Upstream commit a9cd8194e1e6bd09619954721dfaf0f94fe2003e ]
Event timestamps are serialized using ctx->lock, make sure to hold it
over reading all values.
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/events/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4433,6 +4433,8 @@ static int __perf_read_group_add(struct
if (ret)
return ret;
+ raw_spin_lock_irqsave(&ctx->lock, flags);
+
/*
* Since we co-schedule groups, {enabled,running} times of siblings
* will be identical to those of the leader, so we only publish one
@@ -4455,8 +4457,6 @@ static int __perf_read_group_add(struct
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(leader);
- raw_spin_lock_irqsave(&ctx->lock, flags);
-
list_for_each_entry(sub, &leader->sibling_list, group_entry) {
values[n++] += perf_event_count(sub);
if (read_format & PERF_FORMAT_ID)
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.14/perf-tools-fix-leaking-rec_argv-in-error-cases.patch
queue-4.14/locking-refcounts-x86-asm-use-unique-.text-section-for-refcount-exceptions.patch
queue-4.14/selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.patch
queue-4.14/mm-x86-mm-fix-performance-regression-in-get_user_pages_fast.patch
queue-4.14/selftests-x86-ldt_gdt-robustify-against-set_thread_area-and-lar-oddities.patch
queue-4.14/kprobes-use-synchronize_rcu_tasks-for-optprobe-with-config_preempt-y.patch
queue-4.14/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
queue-4.14/kprobes-x86-disable-preemption-in-ftrace-based-jprobes.patch
queue-4.14/locking-refcounts-x86-asm-enable-config_arch_has_refcount.patch
queue-4.14/perf-core-fix-__perf_read_group_add-locking.patch
This is a note to let you know that I've just added the patch titled
PCI: dra7xx: Create functional dependency between PCIe and PHY
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:
pci-dra7xx-create-functional-dependency-between-pcie-and-phy.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 Wed Dec 6 18:04:41 CET 2017
From: Kishon Vijay Abraham I <kishon(a)ti.com>
Date: Mon, 9 Oct 2017 14:33:37 +0530
Subject: PCI: dra7xx: Create functional dependency between PCIe and PHY
From: Kishon Vijay Abraham I <kishon(a)ti.com>
[ Upstream commit 7a4db656a6350f8dd46f711bdef3b0e9c6e3f4cb ]
PCI core access configuration space registers in resume_noirq callbacks.
In the case of dra7xx, PIPE3 PHY connected to PCIe controller has to be
enabled before accessing configuration space registers. Since
PIPE3 PHY is enabled by only configuring control module registers, no
aborts has been observed so far (though during noirq stage, interface
clock of PIPE3 PHY is not enabled).
With new TRM updates, PIPE3 PHY has to be initialized (PIPE3 PHY
registers has to be accessed) as well which requires the interface
clock of PIPE3 PHY to be enabled. The interface clock of PIPE3 PHY is
derived from OCP2SCP and hence PCIe PHY is modeled as a child of
OCP2SCP. Since pm_runtime is not enabled during noirq stage,
pm_runtime_get_sync done in phy_init doesn't enable
OCP2SCP clocks resulting in abort when PIPE3 PHY registers are
accessed.
Create a function dependency between PCIe and PHY here to make
sure PCIe is suspended before PCIe PHY/OCP2SCP and resumed after
PCIe PHY/OCP2SCP.
Suggested-by: Grygorii Strashko <grygorii.strashko(a)ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Sekhar Nori <nsekhar(a)ti.com>
Acked-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/dwc/pci-dra7xx.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -11,6 +11,7 @@
*/
#include <linux/delay.h>
+#include <linux/device.h>
#include <linux/err.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
@@ -594,6 +595,7 @@ static int __init dra7xx_pcie_probe(stru
int i;
int phy_count;
struct phy **phy;
+ struct device_link **link;
void __iomem *base;
struct resource *res;
struct dw_pcie *pci;
@@ -649,11 +651,21 @@ static int __init dra7xx_pcie_probe(stru
if (!phy)
return -ENOMEM;
+ link = devm_kzalloc(dev, sizeof(*link) * phy_count, GFP_KERNEL);
+ if (!link)
+ return -ENOMEM;
+
for (i = 0; i < phy_count; i++) {
snprintf(name, sizeof(name), "pcie-phy%d", i);
phy[i] = devm_phy_get(dev, name);
if (IS_ERR(phy[i]))
return PTR_ERR(phy[i]);
+
+ link[i] = device_link_add(dev, &phy[i]->dev, DL_FLAG_STATELESS);
+ if (!link[i]) {
+ ret = -EINVAL;
+ goto err_link;
+ }
}
dra7xx->base = base;
@@ -732,6 +744,10 @@ err_get_sync:
pm_runtime_disable(dev);
dra7xx_pcie_disable_phy(dra7xx);
+err_link:
+ while (--i >= 0)
+ device_link_del(link[i]);
+
return ret;
}
Patches currently in stable-queue which might be from kishon(a)ti.com are
queue-4.14/pci-dra7xx-create-functional-dependency-between-pcie-and-phy.patch
This is a note to let you know that I've just added the patch titled
mmc: tmio: check mmc_regulator_get_supply return value
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:
mmc-tmio-check-mmc_regulator_get_supply-return-value.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 Wed Dec 6 18:04:41 CET 2017
From: Fabrizio Castro <fabrizio.castro(a)bp.renesas.com>
Date: Fri, 22 Sep 2017 12:22:17 +0100
Subject: mmc: tmio: check mmc_regulator_get_supply return value
From: Fabrizio Castro <fabrizio.castro(a)bp.renesas.com>
[ Upstream commit a3d95d1d4007b1fefd6d8b12db26fda05de05cfb ]
mmc_regulator_get_supply returns -EPROBE_DEFER if either vmmc or
vqmmc regulators had their probing deferred.
vqmmc regulator is needed by UHS to work properly, therefore this
patch checks the value returned by mmc_regulator_get_supply to
make sure we have a reference to both vmmc and vqmmc (if found in
the DT).
Signed-off-by: Fabrizio Castro <fabrizio.castro(a)bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas(a)sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas(a)sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/tmio_mmc_core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1113,8 +1113,11 @@ static int tmio_mmc_init_ocr(struct tmio
{
struct tmio_mmc_data *pdata = host->pdata;
struct mmc_host *mmc = host->mmc;
+ int err;
- mmc_regulator_get_supply(mmc);
+ err = mmc_regulator_get_supply(mmc);
+ if (err)
+ return err;
/* use ocr_mask if no regulator */
if (!mmc->ocr_avail)
Patches currently in stable-queue which might be from fabrizio.castro(a)bp.renesas.com are
queue-4.14/mmc-tmio-check-mmc_regulator_get_supply-return-value.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-msm: fix issue with power irq
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:
mmc-sdhci-msm-fix-issue-with-power-irq.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 Wed Dec 6 18:04:41 CET 2017
From: Subhash Jadavani <subhashj(a)codeaurora.org>
Date: Wed, 27 Sep 2017 11:04:40 +0530
Subject: mmc: sdhci-msm: fix issue with power irq
From: Subhash Jadavani <subhashj(a)codeaurora.org>
[ Upstream commit c7ccee224d2d551f712752c4a16947f6529d6506 ]
SDCC controller reset (SW_RST) during probe may trigger power irq if
previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we
enable the power irq interrupt in GIC (by registering the interrupt
handler), we need to ensure that any pending power irq interrupt status
is acknowledged otherwise power irq interrupt handler would be fired
prematurely.
Signed-off-by: Subhash Jadavani <subhashj(a)codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana(a)codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-msm.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1251,6 +1251,21 @@ static int sdhci_msm_probe(struct platfo
CORE_VENDOR_SPEC_CAPABILITIES0);
}
+ /*
+ * Power on reset state may trigger power irq if previous status of
+ * PWRCTL was either BUS_ON or IO_HIGH_V. So before enabling pwr irq
+ * interrupt in GIC, any pending power irq interrupt should be
+ * acknowledged. Otherwise power irq interrupt handler would be
+ * fired prematurely.
+ */
+ sdhci_msm_voltage_switch(host);
+
+ /*
+ * Ensure that above writes are propogated before interrupt enablement
+ * in GIC.
+ */
+ mb();
+
/* Setup IRQ for handling power/voltage tasks with PMIC */
msm_host->pwr_irq = platform_get_irq_byname(pdev, "pwr_irq");
if (msm_host->pwr_irq < 0) {
@@ -1260,6 +1275,9 @@ static int sdhci_msm_probe(struct platfo
goto clk_disable;
}
+ /* Enable pwr irq interrupts */
+ writel_relaxed(INT_MASK, msm_host->core_mem + CORE_PWRCTL_MASK);
+
ret = devm_request_threaded_irq(&pdev->dev, msm_host->pwr_irq, NULL,
sdhci_msm_pwr_irq, IRQF_ONESHOT,
dev_name(&pdev->dev), host);
Patches currently in stable-queue which might be from subhashj(a)codeaurora.org are
queue-4.14/mmc-sdhci-msm-fix-issue-with-power-irq.patch
This is a note to let you know that I've just added the patch titled
mm, x86/mm: Fix performance regression in get_user_pages_fast()
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:
mm-x86-mm-fix-performance-regression-in-get_user_pages_fast.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 Wed Dec 6 18:04:41 CET 2017
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Date: Sat, 9 Sep 2017 00:56:03 +0300
Subject: mm, x86/mm: Fix performance regression in get_user_pages_fast()
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
[ Upstream commit 5b65c4677a57a1d4414212f9995aa0e46a21ff80 ]
The 0-day test bot found a performance regression that was tracked down to
switching x86 to the generic get_user_pages_fast() implementation:
http://lkml.kernel.org/r/20170710024020.GA26389@yexl-desktop
The regression was caused by the fact that we now use local_irq_save() +
local_irq_restore() in get_user_pages_fast() to disable interrupts.
In x86 implementation local_irq_disable() + local_irq_enable() was used.
The fix is to make get_user_pages_fast() use local_irq_disable(),
leaving local_irq_save() for __get_user_pages_fast() that can be called
with interrupts disabled.
Numbers for pinning a gigabyte of memory, one page a time, 20 repeats:
Before: Average: 14.91 ms, stddev: 0.45 ms
After: Average: 10.76 ms, stddev: 0.18 ms
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Huang Ying <ying.huang(a)intel.com>
Cc: Jonathan Corbet <corbet(a)lwn.net>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Thorsten Leemhuis <regressions(a)leemhuis.info>
Cc: linux-mm(a)kvack.org
Fixes: e585513b76f7 ("x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation")
Link: http://lkml.kernel.org/r/20170908215603.9189-3-kirill.shutemov@linux.intel.…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/gup.c | 97 +++++++++++++++++++++++++++++++++++++--------------------------
1 file changed, 58 insertions(+), 39 deletions(-)
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1707,6 +1707,47 @@ static int gup_p4d_range(pgd_t pgd, unsi
return 1;
}
+static void gup_pgd_range(unsigned long addr, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+ unsigned long next;
+ pgd_t *pgdp;
+
+ pgdp = pgd_offset(current->mm, addr);
+ do {
+ pgd_t pgd = READ_ONCE(*pgdp);
+
+ next = pgd_addr_end(addr, end);
+ if (pgd_none(pgd))
+ return;
+ if (unlikely(pgd_huge(pgd))) {
+ if (!gup_huge_pgd(pgd, pgdp, addr, next, write,
+ pages, nr))
+ return;
+ } else if (unlikely(is_hugepd(__hugepd(pgd_val(pgd))))) {
+ if (!gup_huge_pd(__hugepd(pgd_val(pgd)), addr,
+ PGDIR_SHIFT, next, write, pages, nr))
+ return;
+ } else if (!gup_p4d_range(pgd, addr, next, write, pages, nr))
+ return;
+ } while (pgdp++, addr = next, addr != end);
+}
+
+#ifndef gup_fast_permitted
+/*
+ * Check if it's allowed to use __get_user_pages_fast() for the range, or
+ * we need to fall back to the slow version:
+ */
+bool gup_fast_permitted(unsigned long start, int nr_pages, int write)
+{
+ unsigned long len, end;
+
+ len = (unsigned long) nr_pages << PAGE_SHIFT;
+ end = start + len;
+ return end >= start;
+}
+#endif
+
/*
* Like get_user_pages_fast() except it's IRQ-safe in that it won't fall back to
* the regular GUP. It will only return non-negative values.
@@ -1714,10 +1755,8 @@ static int gup_p4d_range(pgd_t pgd, unsi
int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages)
{
- struct mm_struct *mm = current->mm;
unsigned long addr, len, end;
- unsigned long next, flags;
- pgd_t *pgdp;
+ unsigned long flags;
int nr = 0;
start &= PAGE_MASK;
@@ -1741,45 +1780,15 @@ int __get_user_pages_fast(unsigned long
* block IPIs that come from THPs splitting.
*/
- local_irq_save(flags);
- pgdp = pgd_offset(mm, addr);
- do {
- pgd_t pgd = READ_ONCE(*pgdp);
-
- next = pgd_addr_end(addr, end);
- if (pgd_none(pgd))
- break;
- if (unlikely(pgd_huge(pgd))) {
- if (!gup_huge_pgd(pgd, pgdp, addr, next, write,
- pages, &nr))
- break;
- } else if (unlikely(is_hugepd(__hugepd(pgd_val(pgd))))) {
- if (!gup_huge_pd(__hugepd(pgd_val(pgd)), addr,
- PGDIR_SHIFT, next, write, pages, &nr))
- break;
- } else if (!gup_p4d_range(pgd, addr, next, write, pages, &nr))
- break;
- } while (pgdp++, addr = next, addr != end);
- local_irq_restore(flags);
+ if (gup_fast_permitted(start, nr_pages, write)) {
+ local_irq_save(flags);
+ gup_pgd_range(addr, end, write, pages, &nr);
+ local_irq_restore(flags);
+ }
return nr;
}
-#ifndef gup_fast_permitted
-/*
- * Check if it's allowed to use __get_user_pages_fast() for the range, or
- * we need to fall back to the slow version:
- */
-bool gup_fast_permitted(unsigned long start, int nr_pages, int write)
-{
- unsigned long len, end;
-
- len = (unsigned long) nr_pages << PAGE_SHIFT;
- end = start + len;
- return end >= start;
-}
-#endif
-
/**
* get_user_pages_fast() - pin user pages in memory
* @start: starting user address
@@ -1799,12 +1808,22 @@ bool gup_fast_permitted(unsigned long st
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages)
{
+ unsigned long addr, len, end;
int nr = 0, ret = 0;
start &= PAGE_MASK;
+ addr = start;
+ len = (unsigned long) nr_pages << PAGE_SHIFT;
+ end = start + len;
+
+ if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ,
+ (void __user *)start, len)))
+ return 0;
if (gup_fast_permitted(start, nr_pages, write)) {
- nr = __get_user_pages_fast(start, nr_pages, write, pages);
+ local_irq_disable();
+ gup_pgd_range(addr, end, write, pages, &nr);
+ local_irq_enable();
ret = nr;
}
Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are
queue-4.14/mm-x86-mm-fix-performance-regression-in-get_user_pages_fast.patch
This is a note to let you know that I've just added the patch titled
m68k: fix ColdFire node shift size calculation
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:
m68k-fix-coldfire-node-shift-size-calculation.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 Wed Dec 6 18:04:41 CET 2017
From: Greg Ungerer <gerg(a)linux-m68k.org>
Date: Tue, 5 Sep 2017 22:57:06 +1000
Subject: m68k: fix ColdFire node shift size calculation
From: Greg Ungerer <gerg(a)linux-m68k.org>
[ Upstream commit f55ab8f27548ff3431a6567d400c6757c49fd520 ]
The m68k pg_data_table is a fix size array defined in arch/m68k/mm/init.c.
Index numbers within it are defined based on memory size. But for Coldfire
these don't take into account a non-zero physical RAM base address, and this
causes us to access past the end of this array at system start time.
Change the node shift calculation so that we keep the index inside its range.
Reported-by: Angelo Dureghello <angelo(a)sysam.it>
Tested-by: Angelo Dureghello <angelo(a)sysam.it>
Signed-off-by: Greg Ungerer <gerg(a)linux-m68k.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/m68k/mm/mcfmmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -170,7 +170,7 @@ void __init cf_bootmem_alloc(void)
max_pfn = max_low_pfn = PFN_DOWN(_ramend);
high_memory = (void *)_ramend;
- m68k_virt_to_node_shift = fls(_ramend - _rambase - 1) - 6;
+ m68k_virt_to_node_shift = fls(_ramend - 1) - 6;
module_fixup(NULL, __start_fixup, __stop_fixup);
/* setup bootmem data */
Patches currently in stable-queue which might be from gerg(a)linux-m68k.org are
queue-4.14/m68k-fix-coldfire-node-shift-size-calculation.patch
This is a note to let you know that I've just added the patch titled
locking/refcounts, x86/asm: Use unique .text section for refcount exceptions
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:
locking-refcounts-x86-asm-use-unique-.text-section-for-refcount-exceptions.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 Wed Dec 6 18:04:41 CET 2017
From: Kees Cook <keescook(a)chromium.org>
Date: Sat, 2 Sep 2017 13:09:45 -0700
Subject: locking/refcounts, x86/asm: Use unique .text section for refcount exceptions
From: Kees Cook <keescook(a)chromium.org>
[ Upstream commit 564c9cc84e2adf8a6671c1937f0a9fe3da2a4b0e ]
Using .text.unlikely for refcount exceptions isn't safe because gcc may
move entire functions into .text.unlikely (e.g. in6_dev_dev()), which
would cause any uses of a protected refcount_t function to stay inline
with the function, triggering the protection unconditionally:
.section .text.unlikely,"ax",@progbits
.type in6_dev_get, @function
in6_dev_getx:
.LFB4673:
.loc 2 4128 0
.cfi_startproc
...
lock; incl 480(%rbx)
js 111f
.pushsection .text.unlikely
111: lea 480(%rbx), %rcx
112: .byte 0x0f, 0xff
.popsection
113:
This creates a unique .text..refcount section and adds an additional
test to the exception handler to WARN in the case of having none of OF,
SF, nor ZF set so we can see things like this more easily in the future.
The double dot for the section name keeps it out of the TEXT_MAIN macro
namespace, to avoid collisions and so it can be put at the end with
text.unlikely to keep the cold code together.
See commit:
cb87481ee89db ("kbuild: linker script do not match C names unless LD_DEAD_CODE_DATA_ELIMINATION is configured")
... which matches C names: [a-zA-Z0-9_] but not ".".
Reported-by: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: Elena <elena.reshetova(a)intel.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch <linux-arch(a)vger.kernel.org>
Fixes: 7a46ec0e2f48 ("locking/refcounts, x86/asm: Implement fast refcount overflow protection")
Link: http://lkml.kernel.org/r/1504382986-49301-2-git-send-email-keescook@chromiu…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/refcount.h | 2 +-
arch/x86/mm/extable.c | 7 ++++++-
include/asm-generic/vmlinux.lds.h | 1 +
3 files changed, 8 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/refcount.h
+++ b/arch/x86/include/asm/refcount.h
@@ -15,7 +15,7 @@
* back to the regular execution flow in .text.
*/
#define _REFCOUNT_EXCEPTION \
- ".pushsection .text.unlikely\n" \
+ ".pushsection .text..refcount\n" \
"111:\tlea %[counter], %%" _ASM_CX "\n" \
"112:\t" ASM_UD0 "\n" \
ASM_UNREACHABLE \
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -67,12 +67,17 @@ bool ex_handler_refcount(const struct ex
* wrapped around) will be set. Additionally, seeing the refcount
* reach 0 will set ZF (Zero Flag: result was zero). In each of
* these cases we want a report, since it's a boundary condition.
- *
+ * The SF case is not reported since it indicates post-boundary
+ * manipulations below zero or above INT_MAX. And if none of the
+ * flags are set, something has gone very wrong, so report it.
*/
if (regs->flags & (X86_EFLAGS_OF | X86_EFLAGS_ZF)) {
bool zero = regs->flags & X86_EFLAGS_ZF;
refcount_error_report(regs, zero ? "hit zero" : "overflow");
+ } else if ((regs->flags & X86_EFLAGS_SF) == 0) {
+ /* Report if none of OF, ZF, nor SF are set. */
+ refcount_error_report(regs, "unexpected saturation");
}
return true;
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -459,6 +459,7 @@
#define TEXT_TEXT \
ALIGN_FUNCTION(); \
*(.text.hot TEXT_MAIN .text.fixup .text.unlikely) \
+ *(.text..refcount) \
*(.ref.text) \
MEM_KEEP(init.text) \
MEM_KEEP(exit.text) \
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.14/locking-refcounts-x86-asm-use-unique-.text-section-for-refcount-exceptions.patch
queue-4.14/locking-refcounts-x86-asm-enable-config_arch_has_refcount.patch
This is a note to let you know that I've just added the patch titled
locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT
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:
locking-refcounts-x86-asm-enable-config_arch_has_refcount.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 Wed Dec 6 18:04:41 CET 2017
From: Kees Cook <keescook(a)chromium.org>
Date: Sat, 2 Sep 2017 13:09:46 -0700
Subject: locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT
From: Kees Cook <keescook(a)chromium.org>
[ Upstream commit 39208aa7ecb7d9c4e86df782b5693270313cbab1 ]
With the section inlining bug fixed for the x86 refcount protection,
we can turn the config back on.
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: Elena <elena.reshetova(a)intel.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch <linux-arch(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/1504382986-49301-3-git-send-email-keescook@chromiu…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -56,7 +56,7 @@ config X86
select ARCH_HAS_KCOV if X86_64
select ARCH_HAS_PMEM_API if X86_64
# Causing hangs/crashes, see the commit that added this change for details.
- select ARCH_HAS_REFCOUNT if BROKEN
+ select ARCH_HAS_REFCOUNT
select ARCH_HAS_UACCESS_FLUSHCACHE if X86_64
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_SG_CHAIN
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.14/locking-refcounts-x86-asm-use-unique-.text-section-for-refcount-exceptions.patch
queue-4.14/locking-refcounts-x86-asm-enable-config_arch_has_refcount.patch
This is a note to let you know that I've just added the patch titled
kprobes/x86: Disable preemption in ftrace-based jprobes
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:
kprobes-x86-disable-preemption-in-ftrace-based-jprobes.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 Wed Dec 6 18:04:41 CET 2017
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Tue, 19 Sep 2017 19:01:40 +0900
Subject: kprobes/x86: Disable preemption in ftrace-based jprobes
From: Masami Hiramatsu <mhiramat(a)kernel.org>
[ Upstream commit 5bb4fc2d8641219732eb2bb654206775a4219aca ]
Disable preemption in ftrace-based jprobe handlers as
described in Documentation/kprobes.txt:
"Probe handlers are run with preemption disabled."
This will fix jprobes behavior when CONFIG_PREEMPT=y.
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Alexei Starovoitov <ast(a)fb.com>
Cc: Alexei Starovoitov <ast(a)kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth(a)linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Paul E . McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/150581530024.32348.9863783558598926771.stgit@devbox
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/ftrace.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -26,7 +26,7 @@
#include "common.h"
static nokprobe_inline
-int __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
+void __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb, unsigned long orig_ip)
{
/*
@@ -41,20 +41,21 @@ int __skip_singlestep(struct kprobe *p,
__this_cpu_write(current_kprobe, NULL);
if (orig_ip)
regs->ip = orig_ip;
- return 1;
}
int skip_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
- if (kprobe_ftrace(p))
- return __skip_singlestep(p, regs, kcb, 0);
- else
- return 0;
+ if (kprobe_ftrace(p)) {
+ __skip_singlestep(p, regs, kcb, 0);
+ preempt_enable_no_resched();
+ return 1;
+ }
+ return 0;
}
NOKPROBE_SYMBOL(skip_singlestep);
-/* Ftrace callback handler for kprobes */
+/* Ftrace callback handler for kprobes -- called under preepmt disabed */
void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *ops, struct pt_regs *regs)
{
@@ -77,13 +78,17 @@ void kprobe_ftrace_handler(unsigned long
/* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
regs->ip = ip + sizeof(kprobe_opcode_t);
+ /* To emulate trap based kprobes, preempt_disable here */
+ preempt_disable();
__this_cpu_write(current_kprobe, p);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
- if (!p->pre_handler || !p->pre_handler(p, regs))
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
__skip_singlestep(p, regs, kcb, orig_ip);
+ preempt_enable_no_resched();
+ }
/*
* If pre_handler returns !0, it sets regs->ip and
- * resets current kprobe.
+ * resets current kprobe, and keep preempt count +1.
*/
}
end:
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.14/kprobes-use-synchronize_rcu_tasks-for-optprobe-with-config_preempt-y.patch
queue-4.14/kprobes-x86-disable-preemption-in-ftrace-based-jprobes.patch
This is a note to let you know that I've just added the patch titled
ima: fix hash algorithm initialization
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:
ima-fix-hash-algorithm-initialization.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 Wed Dec 6 18:04:41 CET 2017
From: Boshi Wang <wangboshi(a)huawei.com>
Date: Fri, 20 Oct 2017 16:01:03 +0800
Subject: ima: fix hash algorithm initialization
From: Boshi Wang <wangboshi(a)huawei.com>
[ Upstream commit ebe7c0a7be92bbd34c6ff5b55810546a0ee05bee ]
The hash_setup function always sets the hash_setup_done flag, even
when the hash algorithm is invalid. This prevents the default hash
algorithm defined as CONFIG_IMA_DEFAULT_HASH from being used.
This patch sets hash_setup_done flag only for valid hash algorithms.
Fixes: e7a2ad7eb6f4 "ima: enable support for larger default filedata hash algorithms"
Signed-off-by: Boshi Wang <wangboshi(a)huawei.com>
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_main.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -51,6 +51,8 @@ static int __init hash_setup(char *str)
ima_hash_algo = HASH_ALGO_SHA1;
else if (strncmp(str, "md5", 3) == 0)
ima_hash_algo = HASH_ALGO_MD5;
+ else
+ return 1;
goto out;
}
@@ -60,6 +62,8 @@ static int __init hash_setup(char *str)
break;
}
}
+ if (i == HASH_ALGO__LAST)
+ return 1;
out:
hash_setup_done = 1;
return 1;
Patches currently in stable-queue which might be from wangboshi(a)huawei.com are
queue-4.14/ima-fix-hash-algorithm-initialization.patch
This is a note to let you know that I've just added the patch titled
iio: multiplexer: add NULL check on devm_kzalloc() and devm_kmemdup() return values
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:
iio-multiplexer-add-null-check-on-devm_kzalloc-and-devm_kmemdup-return-values.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 Wed Dec 6 18:04:41 CET 2017
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Thu, 6 Jul 2017 23:53:11 -0500
Subject: iio: multiplexer: add NULL check on devm_kzalloc() and devm_kmemdup() return values
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit dd92d5ea20ef8a42be7aeda08c669c586c730451 ]
Check return values from call to devm_kzalloc() and devm_kmemup()
in order to prevent a NULL pointer dereference.
This issue was detected using Coccinelle and the following semantic patch:
@@
expression x;
identifier fld;
@@
* x = devm_kzalloc(...);
... when != x == NULL
x->fld
Fixes: 7ba9df54b091 ("iio: multiplexer: new iio category and iio-mux driver")
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Acked-by: Peter Rosin <peda(a)axentia.se>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/multiplexer/iio-mux.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/iio/multiplexer/iio-mux.c
+++ b/drivers/iio/multiplexer/iio-mux.c
@@ -285,6 +285,9 @@ static int mux_configure_channel(struct
child->ext_info_cache = devm_kzalloc(dev,
sizeof(*child->ext_info_cache) *
num_ext_info, GFP_KERNEL);
+ if (!child->ext_info_cache)
+ return -ENOMEM;
+
for (i = 0; i < num_ext_info; ++i) {
child->ext_info_cache[i].size = -1;
@@ -309,6 +312,9 @@ static int mux_configure_channel(struct
child->ext_info_cache[i].data = devm_kmemdup(dev, page, ret + 1,
GFP_KERNEL);
+ if (!child->ext_info_cache[i].data)
+ return -ENOMEM;
+
child->ext_info_cache[i].data[ret] = 0;
child->ext_info_cache[i].size = ret;
}
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.14/iio-multiplexer-add-null-check-on-devm_kzalloc-and-devm_kmemdup-return-values.patch
queue-4.14/edac-sb_edac-fix-missing-break-in-switch.patch
This is a note to let you know that I've just added the patch titled
iio: adc: ti-ads1015: add 10% to conversion wait time
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:
iio-adc-ti-ads1015-add-10-to-conversion-wait-time.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 Wed Dec 6 18:04:41 CET 2017
From: Ladislav Michl <ladis(a)linux-mips.org>
Date: Fri, 25 Aug 2017 07:39:16 +0200
Subject: iio: adc: ti-ads1015: add 10% to conversion wait time
From: Ladislav Michl <ladis(a)linux-mips.org>
[ Upstream commit fe895ac88b9fbdf2026f0bfd56c82747bb9d7c48 ]
As user's guide "ADS1015EVM, ADS1115EVM, ADS1015EVM-PDK, ADS1115EVM-PDK
User Guide (Rev. B)" (http://www.ti.com/lit/ug/sbau157b/sbau157b.pdf)
states at page 16:
"Note that both the ADS1115 and ADS1015 have internal clocks with a ±10%
accuracy. If performing FFT tests, frequencies may appear to be incorrect
as a result of this tolerance range.", add those 10% to converion wait
time.
Cc: Daniel Baluta <daniel.baluta(a)gmail.com>
Cc: Jonathan Cameron <jic23(a)kernel.org>
Signed-off-by: Ladislav Michl <ladis(a)linux-mips.org>
Reviewed-by: Akinobu Mita <akinobu.mita(a)gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/adc/ti-ads1015.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/iio/adc/ti-ads1015.c
+++ b/drivers/iio/adc/ti-ads1015.c
@@ -369,6 +369,7 @@ int ads1015_get_adc_result(struct ads101
conv_time = DIV_ROUND_UP(USEC_PER_SEC, data->data_rate[dr_old]);
conv_time += DIV_ROUND_UP(USEC_PER_SEC, data->data_rate[dr]);
+ conv_time += conv_time / 10; /* 10% internal clock inaccuracy */
usleep_range(conv_time, conv_time + 1);
data->conv_invalid = false;
}
Patches currently in stable-queue which might be from ladis(a)linux-mips.org are
queue-4.14/iio-adc-ti-ads1015-add-10-to-conversion-wait-time.patch
This is a note to let you know that I've just added the patch titled
hwmon: (pmbus/core) Prevent unintentional setting of page to 0xFF
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:
hwmon-pmbus-core-prevent-unintentional-setting-of-page-to-0xff.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 Wed Dec 6 18:04:41 CET 2017
From: "Edward A. James" <eajames(a)us.ibm.com>
Date: Fri, 27 Oct 2017 11:55:05 -0500
Subject: hwmon: (pmbus/core) Prevent unintentional setting of page to 0xFF
From: "Edward A. James" <eajames(a)us.ibm.com>
[ Upstream commit 6dcf2fb5e8db3704f50af1f198256cb4e2453f8b ]
The pmbus core may call read/write word data functions with a page value
of -1, intending to perform the operation without setting the page.
However, the read/write word data functions accept only unsigned 8-bit
page numbers, and therefore cannot check for negative page number to
avoid setting the page. This results in setting the page number to 0xFF.
This may result in errors or undefined behavior of some devices
(specifically the ir35221, which allows the page to be set to 0xFF,
but some subsequent operations to read registers may fail).
Switch the pmbus_set_page page parameter to an integer and perform the
check for negative page there. Make read/write functions consistent in
accepting an integer page number parameter.
Signed-off-by: Edward A. James <eajames(a)us.ibm.com>
Fixes: cbcdec6202c9 ("hwmon: (pmbus): Access word data for STATUS_WORD")
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwmon/pmbus/pmbus.h | 6 +++---
drivers/hwmon/pmbus/pmbus_core.c | 25 +++++++++++--------------
2 files changed, 14 insertions(+), 17 deletions(-)
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -404,9 +404,9 @@ extern const struct regulator_ops pmbus_
/* Function declarations */
void pmbus_clear_cache(struct i2c_client *client);
-int pmbus_set_page(struct i2c_client *client, u8 page);
-int pmbus_read_word_data(struct i2c_client *client, u8 page, u8 reg);
-int pmbus_write_word_data(struct i2c_client *client, u8 page, u8 reg, u16 word);
+int pmbus_set_page(struct i2c_client *client, int page);
+int pmbus_read_word_data(struct i2c_client *client, int page, u8 reg);
+int pmbus_write_word_data(struct i2c_client *client, int page, u8 reg, u16 word);
int pmbus_read_byte_data(struct i2c_client *client, int page, u8 reg);
int pmbus_write_byte(struct i2c_client *client, int page, u8 value);
int pmbus_write_byte_data(struct i2c_client *client, int page, u8 reg,
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -136,13 +136,13 @@ void pmbus_clear_cache(struct i2c_client
}
EXPORT_SYMBOL_GPL(pmbus_clear_cache);
-int pmbus_set_page(struct i2c_client *client, u8 page)
+int pmbus_set_page(struct i2c_client *client, int page)
{
struct pmbus_data *data = i2c_get_clientdata(client);
int rv = 0;
int newpage;
- if (page != data->currpage) {
+ if (page >= 0 && page != data->currpage) {
rv = i2c_smbus_write_byte_data(client, PMBUS_PAGE, page);
newpage = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
if (newpage != page)
@@ -158,11 +158,9 @@ int pmbus_write_byte(struct i2c_client *
{
int rv;
- if (page >= 0) {
- rv = pmbus_set_page(client, page);
- if (rv < 0)
- return rv;
- }
+ rv = pmbus_set_page(client, page);
+ if (rv < 0)
+ return rv;
return i2c_smbus_write_byte(client, value);
}
@@ -186,7 +184,8 @@ static int _pmbus_write_byte(struct i2c_
return pmbus_write_byte(client, page, value);
}
-int pmbus_write_word_data(struct i2c_client *client, u8 page, u8 reg, u16 word)
+int pmbus_write_word_data(struct i2c_client *client, int page, u8 reg,
+ u16 word)
{
int rv;
@@ -219,7 +218,7 @@ static int _pmbus_write_word_data(struct
return pmbus_write_word_data(client, page, reg, word);
}
-int pmbus_read_word_data(struct i2c_client *client, u8 page, u8 reg)
+int pmbus_read_word_data(struct i2c_client *client, int page, u8 reg)
{
int rv;
@@ -255,11 +254,9 @@ int pmbus_read_byte_data(struct i2c_clie
{
int rv;
- if (page >= 0) {
- rv = pmbus_set_page(client, page);
- if (rv < 0)
- return rv;
- }
+ rv = pmbus_set_page(client, page);
+ if (rv < 0)
+ return rv;
return i2c_smbus_read_byte_data(client, reg);
}
Patches currently in stable-queue which might be from eajames(a)us.ibm.com are
queue-4.14/hwmon-pmbus-core-prevent-unintentional-setting-of-page-to-0xff.patch
This is a note to let you know that I've just added the patch titled
EDAC, sb_edac: Fix missing break in switch
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:
edac-sb_edac-fix-missing-break-in-switch.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 Wed Dec 6 18:04:41 CET 2017
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Mon, 16 Oct 2017 12:40:29 -0500
Subject: EDAC, sb_edac: Fix missing break in switch
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit a8e9b186f153a44690ad0363a56716e7077ad28c ]
Add missing break statement in order to prevent the code from falling
through.
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Cc: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/20171016174029.GA19757@embeddedor.com
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/sb_edac.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -2498,6 +2498,7 @@ static int ibridge_mci_bind_devs(struct
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA:
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_TA:
pvt->pci_ta = pdev;
+ break;
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_RAS:
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_RAS:
pvt->pci_ras = pdev;
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.14/iio-multiplexer-add-null-check-on-devm_kzalloc-and-devm_kmemdup-return-values.patch
queue-4.14/edac-sb_edac-fix-missing-break-in-switch.patch
This is a note to let you know that I've just added the patch titled
dt-bindings: timer: renesas, cmt: Fix SoC-specific compatible values
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-timer-renesas-cmt-fix-soc-specific-compatible-values.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 Wed Dec 6 18:04:41 CET 2017
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Mon, 18 Sep 2017 15:46:41 +0200
Subject: dt-bindings: timer: renesas, cmt: Fix SoC-specific compatible values
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit e20824e944c3bf4352fcd8d9f446c41b53901e7b ]
While the new family-specific compatible values introduced by commit
6f54cc1adcc8957f ("devicetree: bindings: R-Car Gen2 CMT0 and CMT1
bindings") use the recommended order "<vendor>,<family>-<device>", the
new SoC-specific compatible values still use the old and deprecated
order "<vendor>,<device>-<soc>".
Switch the SoC-specific compatible values to the recommended order while
there are no upstream users of these compatible values yet.
Fixes: 7f03a0ecfdc786c1 ("devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings")
Fixes: 63d9e8ca0dd4bfa4 ("devicetree: bindings: Deprecate property, update example")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Rob Herring <robh(a)kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/timer/renesas,cmt.txt | 24 ++++++++--------
1 file changed, 12 insertions(+), 12 deletions(-)
--- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
@@ -20,16 +20,16 @@ Required Properties:
(CMT1 on sh73a0 and r8a7740)
This is a fallback for the above renesas,cmt-48-* entries.
- - "renesas,cmt0-r8a73a4" for the 32-bit CMT0 device included in r8a73a4.
- - "renesas,cmt1-r8a73a4" for the 48-bit CMT1 device included in r8a73a4.
- - "renesas,cmt0-r8a7790" for the 32-bit CMT0 device included in r8a7790.
- - "renesas,cmt1-r8a7790" for the 48-bit CMT1 device included in r8a7790.
- - "renesas,cmt0-r8a7791" for the 32-bit CMT0 device included in r8a7791.
- - "renesas,cmt1-r8a7791" for the 48-bit CMT1 device included in r8a7791.
- - "renesas,cmt0-r8a7793" for the 32-bit CMT0 device included in r8a7793.
- - "renesas,cmt1-r8a7793" for the 48-bit CMT1 device included in r8a7793.
- - "renesas,cmt0-r8a7794" for the 32-bit CMT0 device included in r8a7794.
- - "renesas,cmt1-r8a7794" for the 48-bit CMT1 device included in r8a7794.
+ - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4.
+ - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4.
+ - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790.
+ - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790.
+ - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791.
+ - "renesas,r8a7791-cmt1" for the 48-bit CMT1 device included in r8a7791.
+ - "renesas,r8a7793-cmt0" for the 32-bit CMT0 device included in r8a7793.
+ - "renesas,r8a7793-cmt1" for the 48-bit CMT1 device included in r8a7793.
+ - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794.
+ - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794.
- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2.
- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2.
@@ -46,7 +46,7 @@ Required Properties:
Example: R8A7790 (R-Car H2) CMT0 and CMT1 nodes
cmt0: timer@ffca0000 {
- compatible = "renesas,cmt0-r8a7790", "renesas,rcar-gen2-cmt0";
+ compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0";
reg = <0 0xffca0000 0 0x1004>;
interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
<0 142 IRQ_TYPE_LEVEL_HIGH>;
@@ -55,7 +55,7 @@ Example: R8A7790 (R-Car H2) CMT0 and CMT
};
cmt1: timer@e6130000 {
- compatible = "renesas,cmt1-r8a7790", "renesas,rcar-gen2-cmt1";
+ compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1";
reg = <0 0xe6130000 0 0x1004>;
interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
<0 121 IRQ_TYPE_LEVEL_HIGH>,
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.14/spi-sh-msiof-fix-dma-transfer-size-check.patch
queue-4.14/dt-bindings-timer-renesas-cmt-fix-soc-specific-compatible-values.patch
This is a note to let you know that I've just added the patch titled
clocksource/drivers/arm_arch_timer: Validate CNTFRQ after enabling frame
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:
clocksource-drivers-arm_arch_timer-validate-cntfrq-after-enabling-frame.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 Wed Dec 6 18:04:41 CET 2017
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Mon, 16 Oct 2017 16:28:38 +0100
Subject: clocksource/drivers/arm_arch_timer: Validate CNTFRQ after enabling frame
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[ Upstream commit 21492e1333a0d07af6968667f128e19088cf5ead ]
The ACPI GTDT code validates the CNTFRQ field of each MMIO timer
frame against the CNTFRQ system register of the current CPU, to
ensure that they are equal, which is mandated by the architecture.
However, reading the CNTFRQ field of a frame is not possible until
the RFRQ bit in the frame's CNTACRn register is set, and doing so
before that willl produce the following error:
arch_timer: [Firmware Bug]: CNTFRQ mismatch: frame @ 0x00000000e0be0000: (0x00000000), CPU: (0x0ee6b280)
arch_timer: Disabling MMIO timers due to CNTFRQ mismatch
arch_timer: Failed to initialize memory-mapped timer.
The reason is that the CNTFRQ field is RES0 if access is not enabled.
So move the validation of CNTFRQ into the loop that iterates over the
timers to find the best frame, but defer it until after we have selected
the best frame, which should also have enabled the RFRQ bit.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clocksource/arm_arch_timer.c | 38 +++++++++++++++++++----------------
1 file changed, 21 insertions(+), 17 deletions(-)
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1268,10 +1268,6 @@ arch_timer_mem_find_best_frame(struct ar
iounmap(cntctlbase);
- if (!best_frame)
- pr_err("Unable to find a suitable frame in timer @ %pa\n",
- &timer_mem->cntctlbase);
-
return best_frame;
}
@@ -1372,6 +1368,8 @@ static int __init arch_timer_mem_of_init
frame = arch_timer_mem_find_best_frame(timer_mem);
if (!frame) {
+ pr_err("Unable to find a suitable frame in timer @ %pa\n",
+ &timer_mem->cntctlbase);
ret = -EINVAL;
goto out;
}
@@ -1420,7 +1418,7 @@ arch_timer_mem_verify_cntfrq(struct arch
static int __init arch_timer_mem_acpi_init(int platform_timer_count)
{
struct arch_timer_mem *timers, *timer;
- struct arch_timer_mem_frame *frame;
+ struct arch_timer_mem_frame *frame, *best_frame = NULL;
int timer_count, i, ret = 0;
timers = kcalloc(platform_timer_count, sizeof(*timers),
@@ -1432,14 +1430,6 @@ static int __init arch_timer_mem_acpi_in
if (ret || !timer_count)
goto out;
- for (i = 0; i < timer_count; i++) {
- ret = arch_timer_mem_verify_cntfrq(&timers[i]);
- if (ret) {
- pr_err("Disabling MMIO timers due to CNTFRQ mismatch\n");
- goto out;
- }
- }
-
/*
* While unlikely, it's theoretically possible that none of the frames
* in a timer expose the combination of feature we want.
@@ -1448,12 +1438,26 @@ static int __init arch_timer_mem_acpi_in
timer = &timers[i];
frame = arch_timer_mem_find_best_frame(timer);
- if (frame)
- break;
+ if (!best_frame)
+ best_frame = frame;
+
+ ret = arch_timer_mem_verify_cntfrq(timer);
+ if (ret) {
+ pr_err("Disabling MMIO timers due to CNTFRQ mismatch\n");
+ goto out;
+ }
+
+ if (!best_frame) /* implies !frame */
+ /*
+ * Only complain about missing suitable frames if we
+ * haven't already found one in a previous iteration.
+ */
+ pr_err("Unable to find a suitable frame in timer @ %pa\n",
+ &timer->cntctlbase);
}
- if (frame)
- ret = arch_timer_mem_frame_register(frame);
+ if (best_frame)
+ ret = arch_timer_mem_frame_register(best_frame);
out:
kfree(timers);
return ret;
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.14/locking-refcounts-x86-asm-use-unique-.text-section-for-refcount-exceptions.patch
queue-4.14/locking-refcounts-x86-asm-enable-config_arch_has_refcount.patch
queue-4.14/clocksource-drivers-arm_arch_timer-validate-cntfrq-after-enabling-frame.patch
This is a note to let you know that I've just added the patch titled
ARM: cpuidle: Correct driver unregistration if init 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:
arm-cpuidle-correct-driver-unregistration-if-init-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 Wed Dec 6 18:04:41 CET 2017
From: Leo Yan <leo.yan(a)linaro.org>
Date: Tue, 10 Oct 2017 13:47:55 +0800
Subject: ARM: cpuidle: Correct driver unregistration if init fails
From: Leo Yan <leo.yan(a)linaro.org>
[ Upstream commit 0f87855d969a87f02048ff5ced7503465d5ab2f1 ]
If cpuidle init fails, the code misses to unregister the driver for
current CPU. Furthermore, we also need to rollback to cancel all
previous CPUs registration; but the code retrieves driver handler by
using function cpuidle_get_driver(), this function returns back
current CPU driver handler but not previous CPU's handler, which leads
to the failure handling code cannot unregister previous CPUs driver.
This commit fixes two mentioned issues, it adds error handling path
'goto out_unregister_drv' for current CPU driver unregistration; and
it is to replace cpuidle_get_driver() with cpuidle_get_cpu_driver(),
the later function can retrieve driver handler for previous CPUs
according to the CPU device handler so can unregister the driver
properly.
This patch also adds extra error handling paths 'goto out_kfree_dev'
and 'goto out_kfree_drv' and adjusts the freeing sentences for previous
CPUs; so make the code more readable for freeing 'dev' and 'drv'
structures.
Suggested-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
Fixes: d50a7d8acd78 (ARM: cpuidle: Support asymmetric idle definition)
Acked-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpuidle/cpuidle-arm.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -104,13 +104,13 @@ static int __init arm_idle_init(void)
ret = dt_init_idle_driver(drv, arm_idle_state_match, 1);
if (ret <= 0) {
ret = ret ? : -ENODEV;
- goto init_fail;
+ goto out_kfree_drv;
}
ret = cpuidle_register_driver(drv);
if (ret) {
pr_err("Failed to register cpuidle driver\n");
- goto init_fail;
+ goto out_kfree_drv;
}
/*
@@ -128,14 +128,14 @@ static int __init arm_idle_init(void)
if (ret) {
pr_err("CPU %d failed to init idle CPU ops\n", cpu);
- goto out_fail;
+ goto out_unregister_drv;
}
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev) {
pr_err("Failed to allocate cpuidle device\n");
ret = -ENOMEM;
- goto out_fail;
+ goto out_unregister_drv;
}
dev->cpu = cpu;
@@ -143,21 +143,25 @@ static int __init arm_idle_init(void)
if (ret) {
pr_err("Failed to register cpuidle device for CPU %d\n",
cpu);
- kfree(dev);
- goto out_fail;
+ goto out_kfree_dev;
}
}
return 0;
-init_fail:
+
+out_kfree_dev:
+ kfree(dev);
+out_unregister_drv:
+ cpuidle_unregister_driver(drv);
+out_kfree_drv:
kfree(drv);
out_fail:
while (--cpu >= 0) {
dev = per_cpu(cpuidle_devices, cpu);
+ drv = cpuidle_get_cpu_driver(dev);
cpuidle_unregister_device(dev);
- kfree(dev);
- drv = cpuidle_get_driver();
cpuidle_unregister_driver(drv);
+ kfree(dev);
kfree(drv);
}
Patches currently in stable-queue which might be from leo.yan(a)linaro.org are
queue-4.14/arm-cpuidle-correct-driver-unregistration-if-init-fails.patch
This is a note to let you know that I've just added the patch titled
xen-netfront: Improve error handling during initialization
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:
xen-netfront-improve-error-handling-during-initialization.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Wed, 8 Feb 2017 10:57:37 +0000
Subject: xen-netfront: Improve error handling during initialization
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit e2e004acc7cbe3c531e752a270a74e95cde3ea48 ]
This fixes a crash when running out of grant refs when creating many
queues across many netdevs.
* If creating queues fails (i.e. there are no grant refs available),
call xenbus_dev_fatal() to ensure that the xenbus device is set to the
closed state.
* If no queues are created, don't call xennet_disconnect_backend as
netdev->real_num_tx_queues will not have been set correctly.
* If setup_netfront() fails, ensure that all the queues created are
cleaned up, not just those that have been set up.
* If any queues were set up and an error occurs, call
xennet_destroy_queues() to clean up the napi context.
* If any fatal error occurs, unregister and destroy the netdev to avoid
leaving around a half setup network device.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netfront.c | 29 +++++++++++------------------
1 file changed, 11 insertions(+), 18 deletions(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1854,27 +1854,19 @@ static int talk_to_netback(struct xenbus
xennet_destroy_queues(info);
err = xennet_create_queues(info, &num_queues);
- if (err < 0)
- goto destroy_ring;
+ if (err < 0) {
+ xenbus_dev_fatal(dev, err, "creating queues");
+ kfree(info->queues);
+ info->queues = NULL;
+ goto out;
+ }
/* Create shared ring, alloc event channel -- for each queue */
for (i = 0; i < num_queues; ++i) {
queue = &info->queues[i];
err = setup_netfront(dev, queue, feature_split_evtchn);
- if (err) {
- /* setup_netfront() will tidy up the current
- * queue on error, but we need to clean up
- * those already allocated.
- */
- if (i > 0) {
- rtnl_lock();
- netif_set_real_num_tx_queues(info->netdev, i);
- rtnl_unlock();
- goto destroy_ring;
- } else {
- goto out;
- }
- }
+ if (err)
+ goto destroy_ring;
}
again:
@@ -1964,9 +1956,10 @@ abort_transaction_no_dev_fatal:
xenbus_transaction_end(xbt, 1);
destroy_ring:
xennet_disconnect_backend(info);
- kfree(info->queues);
- info->queues = NULL;
+ xennet_destroy_queues(info);
out:
+ unregister_netdev(info->netdev);
+ xennet_free_netdev(info->netdev);
return err;
}
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-4.9/xen-netfront-improve-error-handling-during-initialization.patch
This is a note to let you know that I've just added the patch titled
xen-netback: vif counters from int/long to u64
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:
xen-netback-vif-counters-from-int-long-to-u64.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Mart van Santen <mart(a)greenhost.nl>
Date: Fri, 10 Feb 2017 12:02:18 +0000
Subject: xen-netback: vif counters from int/long to u64
From: Mart van Santen <mart(a)greenhost.nl>
[ Upstream commit ebf692f85ff78092cd238166d8d7ec51419f9c02 ]
This patch fixes an issue where the type of counters in the queue(s)
and interface are not in sync (queue counters are int, interface
counters are long), causing incorrect reporting of tx/rx values
of the vif interface and unclear counter overflows.
This patch sets both counters to the u64 type.
Signed-off-by: Mart van Santen <mart(a)greenhost.nl>
Reviewed-by: Paul Durrant <paul.durrant(a)citrix.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netback/common.h | 8 ++++----
drivers/net/xen-netback/interface.c | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -113,10 +113,10 @@ struct xenvif_stats {
* A subset of struct net_device_stats that contains only the
* fields that are updated in netback.c for each queue.
*/
- unsigned int rx_bytes;
- unsigned int rx_packets;
- unsigned int tx_bytes;
- unsigned int tx_packets;
+ u64 rx_bytes;
+ u64 rx_packets;
+ u64 tx_bytes;
+ u64 tx_packets;
/* Additional stats used by xenvif */
unsigned long rx_gso_checksum_fixup;
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -225,10 +225,10 @@ static struct net_device_stats *xenvif_g
{
struct xenvif *vif = netdev_priv(dev);
struct xenvif_queue *queue = NULL;
- unsigned long rx_bytes = 0;
- unsigned long rx_packets = 0;
- unsigned long tx_bytes = 0;
- unsigned long tx_packets = 0;
+ u64 rx_bytes = 0;
+ u64 rx_packets = 0;
+ u64 tx_bytes = 0;
+ u64 tx_packets = 0;
unsigned int index;
spin_lock(&vif->lock);
Patches currently in stable-queue which might be from mart(a)greenhost.nl are
queue-4.9/xen-netback-vif-counters-from-int-long-to-u64.patch
This is a note to let you know that I've just added the patch titled
x86/fpu: Set the xcomp_bv when we fake up a XSAVES area
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:
x86-fpu-set-the-xcomp_bv-when-we-fake-up-a-xsaves-area.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Kevin Hao <haokexin(a)gmail.com>
Date: Sun, 22 Jan 2017 16:50:23 +0800
Subject: x86/fpu: Set the xcomp_bv when we fake up a XSAVES area
From: Kevin Hao <haokexin(a)gmail.com>
[ Upstream commit 4c833368f0bf748d4147bf301b1f95bc8eccb3c0 ]
I got the following calltrace on a Apollo Lake SoC with 32-bit kernel:
WARNING: CPU: 2 PID: 261 at arch/x86/include/asm/fpu/internal.h:363 fpu__restore+0x1f5/0x260
[...]
Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLIRVPA.X64.0138.B35.1608091058 08/09/2016
Call Trace:
dump_stack()
__warn()
? fpu__restore()
warn_slowpath_null()
fpu__restore()
__fpu__restore_sig()
fpu__restore_sig()
restore_sigcontext.isra.9()
sys_sigreturn()
do_int80_syscall_32()
entry_INT80_32()
The reason is that a #GP occurs when executing XRSTORS. The root cause
is that we forget to set the xcomp_bv when we fake up the XSAVES area
in the copyin_to_xsaves() function.
Signed-off-by: Kevin Hao <haokexin(a)gmail.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
Cc: Fenghua Yu <fenghua.yu(a)intel.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas(a)oracle.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Yu-cheng Yu <yu-cheng.yu(a)intel.com>
Link: http://lkml.kernel.org/r/1485075023-30161-1-git-send-email-haokexin@gmail.c…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/fpu/xstate.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -1077,6 +1077,7 @@ int copyin_to_xsaves(const void *kbuf, c
* Add back in the features that came in from userspace:
*/
xsave->header.xfeatures |= xfeatures;
+ xsave->header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT | xsave->header.xfeatures;
return 0;
}
Patches currently in stable-queue which might be from haokexin(a)gmail.com are
queue-4.9/x86-fpu-set-the-xcomp_bv-when-we-fake-up-a-xsaves-area.patch
This is a note to let you know that I've just added the patch titled
x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
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:
x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Dave Hansen <dave.hansen(a)linux.intel.com>
Date: Wed, 18 Oct 2017 10:21:07 -0700
Subject: x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
From: Dave Hansen <dave.hansen(a)linux.intel.com>
[ Upstream commit da20ab35180780e4a6eadc804544f1fa967f3567 ]
We do not have tracepoints for sys_modify_ldt() because we define
it directly instead of using the normal SYSCALL_DEFINEx() macros.
However, there is a reason sys_modify_ldt() does not use the macros:
it has an 'int' return type instead of 'unsigned long'. This is
a bug, but it's a bug cemented in the ABI.
What does this mean? If we return -EINVAL from a function that
returns 'int', we have 0x00000000ffffffea in %rax. But, if we
return -EINVAL from a function returning 'unsigned long', we end
up with 0xffffffffffffffea in %rax, which is wrong.
To work around this and maintain the 'int' behavior while using
the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int'
in both implementations of sys_modify_ldt().
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Reviewed-by: Andy Lutomirski <luto(a)kernel.org>
Reviewed-by: Brian Gerst <brgerst(a)gmail.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20171018172107.1A79C532@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/syscalls.h | 2 +-
arch/x86/kernel/ldt.c | 16 +++++++++++++---
arch/x86/um/ldt.c | 7 +++++--
3 files changed, 19 insertions(+), 6 deletions(-)
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -21,7 +21,7 @@ asmlinkage long sys_ioperm(unsigned long
asmlinkage long sys_iopl(unsigned int);
/* kernel/ldt.c */
-asmlinkage int sys_modify_ldt(int, void __user *, unsigned long);
+asmlinkage long sys_modify_ldt(int, void __user *, unsigned long);
/* kernel/signal.c */
asmlinkage long sys_rt_sigreturn(void);
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -12,6 +12,7 @@
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/smp.h>
+#include <linux/syscalls.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/uaccess.h>
@@ -271,8 +272,8 @@ out:
return error;
}
-asmlinkage int sys_modify_ldt(int func, void __user *ptr,
- unsigned long bytecount)
+SYSCALL_DEFINE3(modify_ldt, int , func , void __user * , ptr ,
+ unsigned long , bytecount)
{
int ret = -ENOSYS;
@@ -290,5 +291,14 @@ asmlinkage int sys_modify_ldt(int func,
ret = write_ldt(ptr, bytecount, 0);
break;
}
- return ret;
+ /*
+ * The SYSCALL_DEFINE() macros give us an 'unsigned long'
+ * return type, but tht ABI for sys_modify_ldt() expects
+ * 'int'. This cast gives us an int-sized value in %rax
+ * for the return code. The 'unsigned' is necessary so
+ * the compiler does not try to sign-extend the negative
+ * return codes into the high half of the register when
+ * taking the value from int->long.
+ */
+ return (unsigned int)ret;
}
--- a/arch/x86/um/ldt.c
+++ b/arch/x86/um/ldt.c
@@ -6,6 +6,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/slab.h>
+#include <linux/syscalls.h>
#include <linux/uaccess.h>
#include <asm/unistd.h>
#include <os.h>
@@ -369,7 +370,9 @@ void free_ldt(struct mm_context *mm)
mm->arch.ldt.entry_count = 0;
}
-int sys_modify_ldt(int func, void __user *ptr, unsigned long bytecount)
+SYSCALL_DEFINE3(modify_ldt, int , func , void __user * , ptr ,
+ unsigned long , bytecount)
{
- return do_modify_ldt_skas(func, ptr, bytecount);
+ /* See non-um modify_ldt() for why we do this cast */
+ return (unsigned int)do_modify_ldt_skas(func, ptr, bytecount);
}
Patches currently in stable-queue which might be from dave.hansen(a)linux.intel.com are
queue-4.9/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
queue-4.9/x86-fpu-set-the-xcomp_bv-when-we-fake-up-a-xsaves-area.patch
This is a note to let you know that I've just added the patch titled
vti6: fix device register to report IFLA_INFO_KIND
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:
vti6-fix-device-register-to-report-ifla_info_kind.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: David Forster <dforster(a)brocade.com>
Date: Fri, 6 Jan 2017 10:27:59 +0000
Subject: vti6: fix device register to report IFLA_INFO_KIND
From: David Forster <dforster(a)brocade.com>
[ Upstream commit 93e246f783e6bd1bc64fdfbfe68b18161f69b28e ]
vti6 interface is registered before the rtnl_link_ops block
is attached. As a result the resulting RTM_NEWLINK is missing
IFLA_INFO_KIND. Re-order attachment of rtnl_link_ops block to fix.
Signed-off-by: Dave Forster <dforster(a)brocade.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>
---
net/ipv6/ip6_vti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -189,12 +189,12 @@ static int vti6_tnl_create2(struct net_d
struct vti6_net *ip6n = net_generic(net, vti6_net_id);
int err;
+ dev->rtnl_link_ops = &vti6_link_ops;
err = register_netdevice(dev);
if (err < 0)
goto out;
strcpy(t->parms.name, dev->name);
- dev->rtnl_link_ops = &vti6_link_ops;
dev_hold(dev);
vti6_tnl_link(ip6n, t);
Patches currently in stable-queue which might be from dforster(a)brocade.com are
queue-4.9/vti6-fix-device-register-to-report-ifla_info_kind.patch
This is a note to let you know that I've just added the patch titled
vfio/spapr: Fix missing mutex unlock when creating a window
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:
vfio-spapr-fix-missing-mutex-unlock-when-creating-a-window.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Date: Wed, 1 Feb 2017 14:26:16 +1100
Subject: vfio/spapr: Fix missing mutex unlock when creating a window
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit 2da64d20a0b20046d688e44f4033efd09157e29d ]
Commit d9c728949ddc ("vfio/spapr: Postpone default window creation")
added an additional exit to the VFIO_IOMMU_SPAPR_TCE_CREATE case and
made it possible to return from tce_iommu_ioctl() without unlocking
container->lock; this fixes the issue.
Fixes: d9c728949ddc ("vfio/spapr: Postpone default window creation")
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Reviewed-by: David Gibson <david(a)gibson.dropbear.id.au>
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/vfio/vfio_iommu_spapr_tce.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -1123,12 +1123,11 @@ static long tce_iommu_ioctl(void *iommu_
mutex_lock(&container->lock);
ret = tce_iommu_create_default_window(container);
- if (ret)
- return ret;
-
- ret = tce_iommu_create_window(container, create.page_shift,
- create.window_size, create.levels,
- &create.start_addr);
+ if (!ret)
+ ret = tce_iommu_create_window(container,
+ create.page_shift,
+ create.window_size, create.levels,
+ &create.start_addr);
mutex_unlock(&container->lock);
Patches currently in stable-queue which might be from aik(a)ozlabs.ru are
queue-4.9/vfio-spapr-fix-missing-mutex-unlock-when-creating-a-window.patch
This is a note to let you know that I've just added the patch titled
usbip: tools: Install all headers needed for libusbip development
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:
usbip-tools-install-all-headers-needed-for-libusbip-development.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ben Hutchings <ben(a)decadent.org.uk>
Date: Sun, 1 Oct 2017 02:18:37 +0100
Subject: usbip: tools: Install all headers needed for libusbip development
From: Ben Hutchings <ben(a)decadent.org.uk>
[ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
usbip_host_driver.h now depends on several additional headers, which
need to be installed along with it.
Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver ...")
Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with ...")
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/tools/usb/usbip/Makefile.am
+++ b/tools/usb/usbip/Makefile.am
@@ -1,6 +1,7 @@
SUBDIRS := libsrc src
includedir = @includedir@/usbip
include_HEADERS := $(addprefix libsrc/, \
- usbip_common.h vhci_driver.h usbip_host_driver.h)
+ usbip_common.h vhci_driver.h usbip_host_driver.h \
+ list.h sysfs_utils.h usbip_host_common.h)
dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8)
Patches currently in stable-queue which might be from ben(a)decadent.org.uk are
queue-4.9/usbip-tools-install-all-headers-needed-for-libusbip-development.patch
This is a note to let you know that I've just added the patch titled
USB: serial: option: add Quectel BG96 id
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-serial-option-add-quectel-bg96-id.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 c654b21ede93845863597de9ad774fd30db5f2ab Mon Sep 17 00:00:00 2001
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
Date: Mon, 20 Nov 2017 19:29:32 +0100
Subject: USB: serial: option: add Quectel BG96 id
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
commit c654b21ede93845863597de9ad774fd30db5f2ab upstream.
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
development board (EVB). The USB id is added to option.c to allow
DIAG,GPS,AT and modem communication with the BG96.
Signed-off-by: Sebastian Sjoholm <ssjoholm(a)mac.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -241,6 +241,7 @@ static void option_instat_callback(struc
/* These Quectel products use Quectel's vendor ID */
#define QUECTEL_PRODUCT_EC21 0x0121
#define QUECTEL_PRODUCT_EC25 0x0125
+#define QUECTEL_PRODUCT_BG96 0x0296
#define CMOTECH_VENDOR_ID 0x16d8
#define CMOTECH_PRODUCT_6001 0x6001
@@ -1185,6 +1186,8 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+ { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
Patches currently in stable-queue which might be from ssjoholm(a)mac.com are
queue-4.9/usb-serial-option-add-quectel-bg96-id.patch
This is a note to let you know that I've just added the patch titled
usb: phy: tahvo: fix error handling in tahvo_usb_probe()
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-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 21 Oct 2017 01:02:07 +0300
Subject: usb: phy: tahvo: fix error handling in tahvo_usb_probe()
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit ce035409bfa892a2fabb89720b542e1b335c3426 ]
If devm_extcon_dev_allocate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Fixes: 860d2686fda7 ("usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API")
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/phy/phy-tahvo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -368,7 +368,8 @@ static int tahvo_usb_probe(struct platfo
tu->extcon = devm_extcon_dev_allocate(&pdev->dev, tahvo_cable);
if (IS_ERR(tu->extcon)) {
dev_err(&pdev->dev, "failed to allocate memory for extcon\n");
- return -ENOMEM;
+ ret = PTR_ERR(tu->extcon);
+ goto err_disable_clk;
}
ret = devm_extcon_dev_register(&pdev->dev, tu->extcon);
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.9/usb-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Fix ExtCompat descriptor validation
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-gadget-f_fs-fix-extcompat-descriptor-validation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Vincent Pelletier <plr.vincent(a)gmail.com>
Date: Thu, 15 Dec 2016 12:47:42 +0000
Subject: usb: gadget: f_fs: Fix ExtCompat descriptor validation
From: Vincent Pelletier <plr.vincent(a)gmail.com>
[ Upstream commit 354bc45bf329494ef6051f3229ef50b9e2a7ea2a ]
Reserved1 is documented as expected to be set to 0, but this test fails
when it it set to 0. Reverse the condition.
Signed-off-by: Vincent Pelletier <plr.vincent(a)gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2263,7 +2263,7 @@ static int __ffs_data_do_os_desc(enum ff
if (len < sizeof(*d) ||
d->bFirstInterfaceNumber >= ffs->interfaces_count ||
- !d->Reserved1)
+ d->Reserved1)
return -EINVAL;
for (i = 0; i < ARRAY_SIZE(d->Reserved2); ++i)
if (d->Reserved2[i])
Patches currently in stable-queue which might be from plr.vincent(a)gmail.com are
queue-4.9/usb-gadget-f_fs-fix-extcompat-descriptor-validation.patch
This is a note to let you know that I've just added the patch titled
usb: dwc2: Fix UDC state tracking
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-dwc2-fix-udc-state-tracking.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 23 Oct 2017 14:32:50 -0700
Subject: usb: dwc2: Fix UDC state tracking
From: John Stultz <john.stultz(a)linaro.org>
[ Upstream commit ce2b21a4e5ce042c0a42c9db8fa9e0f849427d5e ]
It has been noticed that the dwc2 udc state reporting doesn't
seem to work (at least on HiKey boards). Where after the initial
setup, the sysfs /sys/class/udc/f72c0000.usb/state file would
report "configured" no matter the state of the OTG port.
This patch adds a call so that we report to the UDC layer when
the gadget device is disconnected.
This patch does depend on the previous patch ("usb: dwc2:
Improve gadget state disconnection handling") in this patch set
in order to properly work.
Cc: Wei Xu <xuwei5(a)hisilicon.com>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: YongQin Liu <yongqin.liu(a)linaro.org>
Cc: John Youn <johnyoun(a)synopsys.com>
Cc: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Cc: Douglas Anderson <dianders(a)chromium.org>
Cc: Chen Yu <chenyu56(a)huawei.com>
Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: linux-usb(a)vger.kernel.org
Acked-by: Minas Harutyunyan <hminas(a)synopsys.com>
Tested-by: Minas Harutyunyan <hminas(a)synopsys.com>
Reported-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2467,6 +2467,8 @@ void dwc2_hsotg_disconnect(struct dwc2_h
call_gadget(hsotg, disconnect);
hsotg->lx_state = DWC2_L3;
+
+ usb_gadget_set_state(&hsotg->gadget, USB_STATE_NOTATTACHED);
}
/**
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.9/usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
queue-4.9/usb-dwc2-fix-udc-state-tracking.patch
This is a note to let you know that I've just added the patch titled
usb: dwc2: Error out of dwc2_hsotg_ep_disable() if we're in host mode
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-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 23 Oct 2017 14:32:49 -0700
Subject: usb: dwc2: Error out of dwc2_hsotg_ep_disable() if we're in host mode
From: John Stultz <john.stultz(a)linaro.org>
[ Upstream commit 9b481092c2a31a6b630aff9c28f0145bf6683787 ]
We've found that while in host mode, using Android, if one runs
the command:
stop adbd
The existing usb devices being utilized in host mode are disconnected.
This is most visible with usb networking devices.
This seems to be due to adbd closing the file:
/dev/usb-ffs/adb/ep0
Which calls ffs_ep0_release() and the following backtrace:
[<ffffff800875a430>] dwc2_hsotg_ep_disable+0x148/0x150
[<ffffff800875a498>] dwc2_hsotg_udc_stop+0x60/0x110
[<ffffff8008787950>] usb_gadget_remove_driver+0x58/0x78
[<ffffff80087879e4>] usb_gadget_unregister_driver+0x74/0xe8
[<ffffff80087850c0>] unregister_gadget+0x28/0x58
[<ffffff800878511c>] unregister_gadget_item+0x2c/0x40
[<ffffff8008790ea8>] ffs_data_clear+0xe8/0xf8
[<ffffff8008790ed8>] ffs_data_reset+0x20/0x58
[<ffffff8008793218>] ffs_data_closed+0x98/0xe8
[<ffffff80087932d8>] ffs_ep0_release+0x20/0x30
Then when dwc2_hsotg_ep_disable() is called, we call
kill_all_requests() which causes a bunch of the following
messages:
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
init: Service 'adbd' (pid 1915) killed by signal 9
init: Sending signal 9 to service 'adbd' (pid 1915) process group...
init: Successfully killed process cgroup uid 0 pid 1915 in 0ms
init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:15)
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_update_urb_state_abn(): trimming xfer length
And the usb devices connected are basically hung at this point.
It seems like if we're in host mode, we probably shouldn't run
the dwc2_hostg_ep_disable logic, so this patch returns an error
in that case.
With this patch (along with the previous patch in this set), we avoid
the mismatched interrupts and connected usb devices continue to function.
I'm not sure if some other solution would be better here, but this seems
to work, so I wanted to send it out for input on what the right approach
should be.
Cc: Wei Xu <xuwei5(a)hisilicon.com>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: YongQin Liu <yongqin.liu(a)linaro.org>
Cc: John Youn <johnyoun(a)synopsys.com>
Cc: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Cc: Douglas Anderson <dianders(a)chromium.org>
Cc: Chen Yu <chenyu56(a)huawei.com>
Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: linux-usb(a)vger.kernel.org
Acked-by: Minas Harutyunyan <hminas(a)synopsys.com>
Tested-by: Minas Harutyunyan <hminas(a)synopsys.com>
Reported-by: YongQin Liu <yongqin.liu(a)linaro.org>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/gadget.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3117,6 +3117,11 @@ static int dwc2_hsotg_ep_disable(struct
return -EINVAL;
}
+ if (hsotg->op_state != OTG_STATE_B_PERIPHERAL) {
+ dev_err(hsotg->dev, "%s: called in host mode?\n", __func__);
+ return -EINVAL;
+ }
+
epctrl_reg = dir_in ? DIEPCTL(index) : DOEPCTL(index);
spin_lock_irqsave(&hsotg->lock, flags);
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.9/usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
queue-4.9/usb-dwc2-fix-udc-state-tracking.patch
This is a note to let you know that I've just added the patch titled
tools include: Do not use poison with C++
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:
tools-include-do-not-use-poison-with-c.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Date: Thu, 21 Sep 2017 12:12:17 -0300
Subject: tools include: Do not use poison with C++
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
[ Upstream commit 6ae8eefc6c8fe050f057781b70a83262eb0a61ee ]
LIST_POISON[12] are used to initialize list_head and hlist_node
pointers, and do void pointer arithmetic, which C++ doesn't like, so, to
avoid drifting from the kernel by introducing some HLIST_POISON to do
away with void pointer math, just make those poisoned pointers be NULL
when building it with a C++ compiler.
Noticed with:
$ make LLVM_CONFIG=/usr/bin/llvm-config-3.9 LIBCLANGLLVM=1
CXX util/c++/clang.o
CXX util/c++/clang-test.o
In file included from /home/lizj/linux/tools/include/linux/list.h:5:0,
from /home/lizj/linux/tools/perf/util/namespaces.h:13,
from /home/lizj/linux/tools/perf/util/util.h:15,
from /home/lizj/linux/tools/perf/util/util-cxx.h:20,
from util/c++/clang-c.h:5,
from util/c++/clang-test.cpp:2:
/home/lizj/linux/tools/include/linux/list.h: In function ‘void list_del(list_head*)’:
/home/lizj/linux/tools/include/linux/poison.h:14:31: error: pointer of type ‘void *’ used in arithmetic [-Werror=pointer-arith]
# define POISON_POINTER_DELTA 0
^
/home/lizj/linux/tools/include/linux/poison.h:22:41: note: in expansion of macro ‘POISON_POINTER_DELTA’
#define LIST_POISON1 ((void *) 0x100 + POISON_POINTER_DELTA)
^
/home/lizj/linux/tools/include/linux/list.h:107:16: note: in expansion of macro ‘LIST_POISON1’
entry->next = LIST_POISON1;
^
In file included from /home/lizj/linux/tools/perf/util/namespaces.h:13:0,
from /home/lizj/linux/tools/perf/util/util.h:15,
from /home/lizj/linux/tools/perf/util/util-cxx.h:20,
from util/c++/clang-c.h:5,
from util/c++/clang-test.cpp:2:
/home/lizj/linux/tools/include/linux/list.h:107:14: error: invalid conversion from ‘void*’ to ‘list_head*’ [-fpermissive]
Reported-by: Li Zhijian <lizhijian(a)cn.fujitsu.com>
Cc: Adrian Hunter <adrian.hunter(a)intel.com>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: David Ahern <dsahern(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Philip Li <philip.li(a)intel.com>
Cc: Wang Nan <wangnan0(a)huawei.com>
Link: http://lkml.kernel.org/n/tip-m5ei2o0mjshucbr28baf5lqz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/include/linux/poison.h | 5 +++++
1 file changed, 5 insertions(+)
--- a/tools/include/linux/poison.h
+++ b/tools/include/linux/poison.h
@@ -14,6 +14,10 @@
# define POISON_POINTER_DELTA 0
#endif
+#ifdef __cplusplus
+#define LIST_POISON1 NULL
+#define LIST_POISON2 NULL
+#else
/*
* These are non-NULL pointers that will result in page faults
* under normal circumstances, used to verify that nobody uses
@@ -21,6 +25,7 @@
*/
#define LIST_POISON1 ((void *) 0x100 + POISON_POINTER_DELTA)
#define LIST_POISON2 ((void *) 0x200 + POISON_POINTER_DELTA)
+#endif
/********** include/linux/timer.h **********/
/*
Patches currently in stable-queue which might be from acme(a)redhat.com are
queue-4.9/perf-test-attr-fix-ignored-test-case-result.patch
queue-4.9/perf-x86-intel-account-interrupts-for-pebs-errors.patch
queue-4.9/tools-include-do-not-use-poison-with-c.patch
This is a note to let you know that I've just added the patch titled
tipc: fix nametbl_lock soft lockup at module exit
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:
tipc-fix-nametbl_lock-soft-lockup-at-module-exit.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com>
Date: Tue, 24 Jan 2017 13:00:46 +0100
Subject: tipc: fix nametbl_lock soft lockup at module exit
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com>
[ Upstream commit 9dc3abdd1f7ea524e8552e0a3ef01219892ed1f4 ]
Commit 333f796235a527 ("tipc: fix a race condition leading to
subscriber refcnt bug") reveals a soft lockup while acquiring
nametbl_lock.
Before commit 333f796235a527, we call tipc_conn_shutdown() from
tipc_close_conn() in the context of tipc_topsrv_stop(). In that
context, we are allowed to grab the nametbl_lock.
Commit 333f796235a527, moved tipc_conn_release (renamed from
tipc_conn_shutdown) to the connection refcount cleanup. This allows
either tipc_nametbl_withdraw() or tipc_topsrv_stop() to the cleanup.
Since tipc_exit_net() first calls tipc_topsrv_stop() and then
tipc_nametble_withdraw() increases the chances for the later to
perform the connection cleanup.
The soft lockup occurs in the call chain of tipc_nametbl_withdraw(),
when it performs the tipc_conn_kref_release() as it tries to grab
nametbl_lock again while holding it already.
tipc_nametbl_withdraw() grabs nametbl_lock
tipc_nametbl_remove_publ()
tipc_subscrp_report_overlap()
tipc_subscrp_send_event()
tipc_conn_sendmsg()
<< if (con->flags != CF_CONNECTED) we do conn_put(),
triggering the cleanup as refcount=0. >>
tipc_conn_kref_release
tipc_sock_release
tipc_conn_release
tipc_subscrb_delete
tipc_subscrp_delete
tipc_nametbl_unsubscribe << Soft Lockup >>
The previous changes in this series fixes the race conditions fixed
by commit 333f796235a527. Hence we can now revert the commit.
Fixes: 333f796235a52727 ("tipc: fix a race condition leading to subscriber refcnt bug")
Reported-and-Tested-by: John Thompson <thompa.atl(a)gmail.com>
Acked-by: Ying Xue <ying.xue(a)windriver.com>
Acked-by: Jon Maloy <jon.maloy(a)ericsson.com>
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.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>
---
net/tipc/server.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
--- a/net/tipc/server.c
+++ b/net/tipc/server.c
@@ -86,7 +86,6 @@ struct outqueue_entry {
static void tipc_recv_work(struct work_struct *work);
static void tipc_send_work(struct work_struct *work);
static void tipc_clean_outqueues(struct tipc_conn *con);
-static void tipc_sock_release(struct tipc_conn *con);
static void tipc_conn_kref_release(struct kref *kref)
{
@@ -104,7 +103,6 @@ static void tipc_conn_kref_release(struc
}
saddr->scope = -TIPC_NODE_SCOPE;
kernel_bind(sock, (struct sockaddr *)saddr, sizeof(*saddr));
- tipc_sock_release(con);
sock_release(sock);
con->sock = NULL;
@@ -194,19 +192,15 @@ static void tipc_unregister_callbacks(st
write_unlock_bh(&sk->sk_callback_lock);
}
-static void tipc_sock_release(struct tipc_conn *con)
+static void tipc_close_conn(struct tipc_conn *con)
{
struct tipc_server *s = con->server;
- if (con->conid)
- s->tipc_conn_release(con->conid, con->usr_data);
-
- tipc_unregister_callbacks(con);
-}
-
-static void tipc_close_conn(struct tipc_conn *con)
-{
if (test_and_clear_bit(CF_CONNECTED, &con->flags)) {
+ tipc_unregister_callbacks(con);
+
+ if (con->conid)
+ s->tipc_conn_release(con->conid, con->usr_data);
/* We shouldn't flush pending works as we may be in the
* thread. In fact the races with pending rx/tx work structs
Patches currently in stable-queue which might be from parthasarathy.bhuvaragan(a)ericsson.com are
queue-4.9/tipc-fix-nametbl_lock-soft-lockup-at-module-exit.patch
queue-4.9/tipc-fix-cleanup-at-module-unload.patch
This is a note to let you know that I've just added the patch titled
tipc: fix cleanup at module unload
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:
tipc-fix-cleanup-at-module-unload.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com>
Date: Tue, 24 Jan 2017 13:00:48 +0100
Subject: tipc: fix cleanup at module unload
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com>
[ Upstream commit 35e22e49a5d6a741ebe7f2dd280b2052c3003ef7 ]
In tipc_server_stop(), we iterate over the connections with limiting
factor as server's idr_in_use. We ignore the fact that this variable
is decremented in tipc_close_conn(), leading to premature exit.
In this commit, we iterate until the we have no connections left.
Acked-by: Ying Xue <ying.xue(a)windriver.com>
Acked-by: Jon Maloy <jon.maloy(a)ericsson.com>
Tested-by: John Thompson <thompa.atl(a)gmail.com>
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.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>
---
net/tipc/server.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/net/tipc/server.c
+++ b/net/tipc/server.c
@@ -619,14 +619,12 @@ int tipc_server_start(struct tipc_server
void tipc_server_stop(struct tipc_server *s)
{
struct tipc_conn *con;
- int total = 0;
int id;
spin_lock_bh(&s->idr_lock);
- for (id = 0; total < s->idr_in_use; id++) {
+ for (id = 0; s->idr_in_use; id++) {
con = idr_find(&s->conn_idr, id);
if (con) {
- total++;
spin_unlock_bh(&s->idr_lock);
tipc_close_conn(con);
spin_lock_bh(&s->idr_lock);
Patches currently in stable-queue which might be from parthasarathy.bhuvaragan(a)ericsson.com are
queue-4.9/tipc-fix-nametbl_lock-soft-lockup-at-module-exit.patch
queue-4.9/tipc-fix-cleanup-at-module-unload.patch
This is a note to let you know that I've just added the patch titled
tcp: correct memory barrier usage in tcp_check_space()
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:
tcp-correct-memory-barrier-usage-in-tcp_check_space.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Jason Baron <jbaron(a)akamai.com>
Date: Tue, 24 Jan 2017 21:49:41 -0500
Subject: tcp: correct memory barrier usage in tcp_check_space()
From: Jason Baron <jbaron(a)akamai.com>
[ Upstream commit 56d806222ace4c3aeae516cd7a855340fb2839d8 ]
sock_reset_flag() maps to __clear_bit() not the atomic version clear_bit().
Thus, we need smp_mb(), smp_mb__after_atomic() is not sufficient.
Fixes: 3c7151275c0c ("tcp: add memory barriers to write space paths")
Cc: Eric Dumazet <eric.dumazet(a)gmail.com>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Signed-off-by: Jason Baron <jbaron(a)akamai.com>
Acked-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Oleg Nesterov <oleg(a)redhat.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>
---
net/ipv4/tcp_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5081,7 +5081,7 @@ static void tcp_check_space(struct sock
if (sock_flag(sk, SOCK_QUEUE_SHRUNK)) {
sock_reset_flag(sk, SOCK_QUEUE_SHRUNK);
/* pairs with tcp_poll() */
- smp_mb__after_atomic();
+ smp_mb();
if (sk->sk_socket &&
test_bit(SOCK_NOSPACE, &sk->sk_socket->flags))
tcp_new_space(sk);
Patches currently in stable-queue which might be from jbaron(a)akamai.com are
queue-4.9/tcp-correct-memory-barrier-usage-in-tcp_check_space.patch
This is a note to let you know that I've just added the patch titled
sysrq : fix Show Regs call trace on ARM
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:
sysrq-fix-show-regs-call-trace-on-arm.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Jibin Xu <jibin.xu(a)windriver.com>
Date: Sun, 10 Sep 2017 20:11:42 -0700
Subject: sysrq : fix Show Regs call trace on ARM
From: Jibin Xu <jibin.xu(a)windriver.com>
[ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]
When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 >/proc/sys/kernel/sysrq
echo p >/proc/sysrq-trigger
kernel will print call trace as below:
sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[<ffffff8008088e80>] dump_backtrace+0x0/0x1d0
[<ffffff8008089074>] show_stack+0x24/0x30
[<ffffff8008447970>] dump_stack+0x90/0xb0
[<ffffff8008463950>] check_preemption_disabled+0x100/0x108
[<ffffff8008463998>] __this_cpu_preempt_check+0x18/0x20
[<ffffff80084c9194>] sysrq_handle_showregs+0x1c/0x40
[<ffffff80084c9c7c>] __handle_sysrq+0x12c/0x1a0
[<ffffff80084ca140>] write_sysrq_trigger+0x60/0x70
[<ffffff8008251e00>] proc_reg_write+0x90/0xd0
[<ffffff80081f1788>] __vfs_write+0x48/0x90
[<ffffff80081f241c>] vfs_write+0xa4/0x190
[<ffffff80081f3354>] SyS_write+0x54/0xb0
[<ffffff80080833f0>] el0_svc_naked+0x24/0x28
This can be seen on a common board like an r-pi3.
This happens because when echo p >/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.
Signed-off-by: Jibin Xu <jibin.xu(a)windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/sysrq.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -243,8 +243,10 @@ static void sysrq_handle_showallcpus(int
* architecture has no support for it:
*/
if (!trigger_all_cpu_backtrace()) {
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+ if (in_irq())
+ regs = get_irq_regs();
if (regs) {
pr_info("CPU%d:\n", smp_processor_id());
show_regs(regs);
@@ -263,7 +265,10 @@ static struct sysrq_key_op sysrq_showall
static void sysrq_handle_showregs(int key)
{
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+
+ if (in_irq())
+ regs = get_irq_regs();
if (regs)
show_regs(regs);
perf_event_print_debug();
Patches currently in stable-queue which might be from jibin.xu(a)windriver.com are
queue-4.9/sysrq-fix-show-regs-call-trace-on-arm.patch
This is a note to let you know that I've just added the patch titled
staging: rtl8188eu: avoid a null dereference on pmlmepriv
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:
staging-rtl8188eu-avoid-a-null-dereference-on-pmlmepriv.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 20 Oct 2017 20:40:24 +0200
Subject: staging: rtl8188eu: avoid a null dereference on pmlmepriv
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 123c0aab0050cd0e07ce18e453389fbbb0a5a425 ]
There is a check on pmlmepriv before dereferencing it when
vfree'ing pmlmepriv->free_bss_buf however the previous call
to rtw_free_mlme_priv_ie_data deferences pmlmepriv causing
a null pointer deference if it is null. Avoid this by also
calling rtw_free_mlme_priv_ie_data if the pointer is non-null.
Detected by CoverityScan, CID#1230262 ("Dereference before null check")
Fixes: 7b464c9fa5cc ("staging: r8188eu: Add files for new driver - part 4")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -107,10 +107,10 @@ void rtw_free_mlme_priv_ie_data(struct m
void rtw_free_mlme_priv(struct mlme_priv *pmlmepriv)
{
- rtw_free_mlme_priv_ie_data(pmlmepriv);
-
- if (pmlmepriv)
+ if (pmlmepriv) {
+ rtw_free_mlme_priv_ie_data(pmlmepriv);
vfree(pmlmepriv->free_bss_buf);
+ }
}
struct wlan_network *_rtw_alloc_network(struct mlme_priv *pmlmepriv)
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.9/staging-rtl8188eu-avoid-a-null-dereference-on-pmlmepriv.patch
queue-4.9/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
This is a note to let you know that I've just added the patch titled
staging: greybus: loopback: Fix iteration count on async path
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:
staging-greybus-loopback-fix-iteration-count-on-async-path.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
Date: Mon, 6 Nov 2017 01:32:20 +0000
Subject: staging: greybus: loopback: Fix iteration count on async path
From: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
[ Upstream commit 44b02da39210e6dd67e39ff1f48d30c56d384240 ]
Commit 12927835d211 ("greybus: loopback: Add asynchronous bi-directional
support") does what it says on the tin - namely, adds support for
asynchronous bi-directional loopback operations.
What it neglects to do though is increment the per-connection
gb->iteration_count on an asynchronous operation error. This patch fixes
that omission.
Fixes: 12927835d211 ("greybus: loopback: Add asynchronous bi-directional support")
Signed-off-by: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
Reported-by: Mitch Tasman <tasman(a)leaflabs.com>
Reviewed-by: Johan Hovold <johan(a)kernel.org>
Cc: Alex Elder <elder(a)kernel.org>
Cc: Mitch Tasman <tasman(a)leaflabs.com>
Cc: greybus-dev(a)lists.linaro.org
Cc: devel(a)driverdev.osuosl.org
Cc: linux-kernel(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/greybus/loopback.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -1034,8 +1034,10 @@ static int gb_loopback_fn(void *data)
error = gb_loopback_async_sink(gb, size);
}
- if (error)
+ if (error) {
gb->error++;
+ gb->iteration_count++;
+ }
} else {
/* We are effectively single threaded here */
if (type == GB_LOOPBACK_TYPE_PING)
Patches currently in stable-queue which might be from pure.logic(a)nexus-software.ie are
queue-4.9/staging-greybus-loopback-fix-iteration-count-on-async-path.patch
This is a note to let you know that I've just added the patch titled
spi: spi-axi: fix potential use-after-free after deregistration
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:
spi-spi-axi-fix-potential-use-after-free-after-deregistration.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Johan Hovold <johan(a)kernel.org>
Date: Mon, 30 Oct 2017 11:35:27 +0100
Subject: spi: spi-axi: fix potential use-after-free after deregistration
From: Johan Hovold <johan(a)kernel.org>
[ Upstream commit 4d5e0689dc9d5640ad46cdfbe1896b74d8df1661 ]
Take an extra reference to the controller before deregistering it to
prevent use-after-free in the interrupt handler in case an interrupt
fires before the line is disabled.
Fixes: b1353d1c1d45 ("spi: Add Analog Devices AXI SPI Engine controller support")
Acked-by: Lars-Peter Clausen <lars(a)metafoo.de>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-axi-spi-engine.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/spi/spi-axi-spi-engine.c
+++ b/drivers/spi/spi-axi-spi-engine.c
@@ -553,7 +553,7 @@ err_put_master:
static int spi_engine_remove(struct platform_device *pdev)
{
- struct spi_master *master = platform_get_drvdata(pdev);
+ struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
struct spi_engine *spi_engine = spi_master_get_devdata(master);
int irq = platform_get_irq(pdev, 0);
@@ -561,6 +561,8 @@ static int spi_engine_remove(struct plat
free_irq(irq, master);
+ spi_master_put(master);
+
writel_relaxed(0xff, spi_engine->base + SPI_ENGINE_REG_INT_PENDING);
writel_relaxed(0x00, spi_engine->base + SPI_ENGINE_REG_INT_ENABLE);
writel_relaxed(0x01, spi_engine->base + SPI_ENGINE_REG_RESET);
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.9/staging-greybus-loopback-fix-iteration-count-on-async-path.patch
queue-4.9/spi-spi-axi-fix-potential-use-after-free-after-deregistration.patch
queue-4.9/usb-serial-option-add-quectel-bg96-id.patch
This is a note to let you know that I've just added the patch titled
spi: sh-msiof: Fix DMA transfer size check
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:
spi-sh-msiof-fix-dma-transfer-size-check.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Date: Thu, 2 Nov 2017 10:32:36 +0100
Subject: spi: sh-msiof: Fix DMA transfer size check
From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support")
Signed-off-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Dirk Behme <dirk.behme(a)de.bosch.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-sh-msiof.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -862,7 +862,7 @@ static int sh_msiof_transfer_one(struct
break;
copy32 = copy_bswap32;
} else if (bits <= 16) {
- if (l & 1)
+ if (l & 3)
break;
copy32 = copy_wswap32;
} else {
Patches currently in stable-queue which might be from hiromitsu.yamasaki.ym(a)renesas.com are
queue-4.9/spi-sh-msiof-fix-dma-transfer-size-check.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
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:
serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sat, 28 Oct 2017 11:35:49 +0200
Subject: serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
From: Lukas Wunner <lukas(a)wunner.de>
[ Upstream commit 3236a965486ba0c6043cf2c7b51943d8b382ae29 ]
This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND
and SER_RS485_RTS_AFTER_SEND have the same value. If they do, it means
the user has passed in invalid data with the TIOCSRS485 ioctl()
since RTS must have a different polarity when sending and when not
sending. In this case, rs485 mode is not enabled (the RS485_URA bit
is not set in the RS485 Enable Register) and this is supposed to be
signaled back to the user by clearing the SER_RS485_ENABLED bit in
struct serial_rs485 ... except a missing tilde character is preventing
that from happening.
Fixes: 28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART")
Cc: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Cc: "Ji-Ze Hong (Peter Hong)" <hpeter(a)gmail.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_fintek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/8250/8250_fintek.c
+++ b/drivers/tty/serial/8250/8250_fintek.c
@@ -121,7 +121,7 @@ static int fintek_8250_rs485_config(stru
if ((!!(rs485->flags & SER_RS485_RTS_ON_SEND)) ==
(!!(rs485->flags & SER_RS485_RTS_AFTER_SEND)))
- rs485->flags &= SER_RS485_ENABLED;
+ rs485->flags &= ~SER_RS485_ENABLED;
else
config |= RS485_URA;
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.9/serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch
This is a note to let you know that I've just added the patch titled
serial: 8250: Preserve DLD[7:4] for PORT_XR17V35X
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:
serial-8250-preserve-dld-for-port_xr17v35x.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Aaron Sierra <asierra(a)xes-inc.com>
Date: Wed, 4 Oct 2017 10:01:28 -0500
Subject: serial: 8250: Preserve DLD[7:4] for PORT_XR17V35X
From: Aaron Sierra <asierra(a)xes-inc.com>
[ Upstream commit 0ab84da2e076948c49d36197ee7d254125c53eab ]
The upper four bits of the XR17V35x fractional divisor register (DLD)
control general chip function (RS-485 direction pin polarity, multidrop
mode, XON/XOFF parity check, and fast IR mode). Don't allow these bits
to be clobbered when setting the baudrate.
Signed-off-by: Aaron Sierra <asierra(a)xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2526,8 +2526,11 @@ static void serial8250_set_divisor(struc
serial_dl_write(up, quot);
/* XR17V35x UARTs have an extra fractional divisor register (DLD) */
- if (up->port.type == PORT_XR17V35X)
+ if (up->port.type == PORT_XR17V35X) {
+ /* Preserve bits not related to baudrate; DLD[7:4]. */
+ quot_frac |= serial_port_in(port, 0x2) & 0xf0;
serial_port_out(port, 0x2, quot_frac);
+ }
}
static unsigned int serial8250_get_baud_rate(struct uart_port *port,
Patches currently in stable-queue which might be from asierra(a)xes-inc.com are
queue-4.9/serial-8250-preserve-dld-for-port_xr17v35x.patch
This is a note to let you know that I've just added the patch titled
selftests/x86/ldt_get: Add a few additional tests for limits
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:
selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Andy Lutomirski <luto(a)kernel.org>
Date: Sat, 4 Nov 2017 04:19:52 -0700
Subject: selftests/x86/ldt_get: Add a few additional tests for limits
From: Andy Lutomirski <luto(a)kernel.org>
[ Upstream commit fec8f5ae1715a01c72ad52cb2ecd8aacaf142302 ]
We weren't testing the .limit and .limit_in_pages fields very well.
Add more tests.
This addition seems to trigger the "bits 16:19 are undefined" issue
that was fixed in an earlier patch. I think that, at least on my
CPU, the high nibble of the limit ends in LAR bits 16:19.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bpetkov(a)suse.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/5601c15ea9b3113d288953fd2838b18bedf6bc67.150979432…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/x86/ldt_gdt.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
--- a/tools/testing/selftests/x86/ldt_gdt.c
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -360,9 +360,24 @@ static void do_simple_tests(void)
install_invalid(&desc, false);
desc.seg_not_present = 0;
- desc.read_exec_only = 0;
desc.seg_32bit = 1;
+ desc.read_exec_only = 0;
+ desc.limit = 0xfffff;
+
install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA | AR_S | AR_P | AR_DB);
+
+ desc.limit_in_pages = 1;
+
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA | AR_S | AR_P | AR_DB | AR_G);
+ desc.read_exec_only = 1;
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RODATA | AR_S | AR_P | AR_DB | AR_G);
+ desc.contents = 1;
+ desc.read_exec_only = 0;
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA_EXPDOWN | AR_S | AR_P | AR_DB | AR_G);
+ desc.read_exec_only = 1;
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RODATA_EXPDOWN | AR_S | AR_P | AR_DB | AR_G);
+
+ desc.limit = 0;
install_invalid(&desc, true);
}
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.9/selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.patch
queue-4.9/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
queue-4.9/x86-fpu-set-the-xcomp_bv-when-we-fake-up-a-xsaves-area.patch
This is a note to let you know that I've just added the patch titled
s390/pci: do not require AIS facility
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:
s390-pci-do-not-require-ais-facility.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
Date: Mon, 30 Oct 2017 14:38:58 +0100
Subject: s390/pci: do not require AIS facility
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
[ Upstream commit 48070c73058be6de9c0d754d441ed7092dfc8f12 ]
As of today QEMU does not provide the AIS facility to its guest. This
prevents Linux guests from using PCI devices as the ais facility is
checked during init. As this is just a performance optimization, we can
move the ais check into the code where we need it (calling the SIC
instruction). This is used at initialization and on interrupt. Both
places do not require any serialization, so we can simply skip the
instruction.
Since we will now get all interrupts, we can also avoid the 2nd scan.
As we can have multiple interrupts in parallel we might trigger spurious
irqs more often for the non-AIS case but the core code can handle that.
Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Reviewed-by: Pierre Morel <pmorel(a)linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic(a)linux.vnet.ibm.com>
Acked-by: Sebastian Ott <sebott(a)linux.vnet.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/include/asm/pci_insn.h | 2 +-
arch/s390/pci/pci.c | 5 +++--
arch/s390/pci/pci_insn.c | 6 +++++-
3 files changed, 9 insertions(+), 4 deletions(-)
--- a/arch/s390/include/asm/pci_insn.h
+++ b/arch/s390/include/asm/pci_insn.h
@@ -81,6 +81,6 @@ int zpci_refresh_trans(u64 fn, u64 addr,
int zpci_load(u64 *data, u64 req, u64 offset);
int zpci_store(u64 data, u64 req, u64 offset);
int zpci_store_block(const u64 *data, u64 req, u64 offset);
-void zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc);
+int zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc);
#endif
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -354,7 +354,8 @@ static void zpci_irq_handler(struct airq
/* End of second scan with interrupts on. */
break;
/* First scan complete, reenable interrupts. */
- zpci_set_irq_ctrl(SIC_IRQ_MODE_SINGLE, NULL, PCI_ISC);
+ if (zpci_set_irq_ctrl(SIC_IRQ_MODE_SINGLE, NULL, PCI_ISC))
+ break;
si = 0;
continue;
}
@@ -928,7 +929,7 @@ static int __init pci_base_init(void)
if (!s390_pci_probe)
return 0;
- if (!test_facility(69) || !test_facility(71) || !test_facility(72))
+ if (!test_facility(69) || !test_facility(71))
return 0;
rc = zpci_debug_init();
--- a/arch/s390/pci/pci_insn.c
+++ b/arch/s390/pci/pci_insn.c
@@ -7,6 +7,7 @@
#include <linux/export.h>
#include <linux/errno.h>
#include <linux/delay.h>
+#include <asm/facility.h>
#include <asm/pci_insn.h>
#include <asm/pci_debug.h>
#include <asm/processor.h>
@@ -91,11 +92,14 @@ int zpci_refresh_trans(u64 fn, u64 addr,
}
/* Set Interruption Controls */
-void zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc)
+int zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc)
{
+ if (!test_facility(72))
+ return -EIO;
asm volatile (
" .insn rsy,0xeb00000000d1,%[ctl],%[isc],%[u]\n"
: : [ctl] "d" (ctl), [isc] "d" (isc << 27), [u] "Q" (*unused));
+ return 0;
}
/* PCI Load */
Patches currently in stable-queue which might be from borntraeger(a)de.ibm.com are
queue-4.9/s390-pci-do-not-require-ais-facility.patch
This is a note to let you know that I've just added the patch titled
RDMA/qedr: Return success when not changing QP state
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:
rdma-qedr-return-success-when-not-changing-qp-state.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ram Amrani <Ram.Amrani(a)Cavium.com>
Date: Tue, 24 Jan 2017 13:50:34 +0200
Subject: RDMA/qedr: Return success when not changing QP state
From: Ram Amrani <Ram.Amrani(a)Cavium.com>
[ Upstream commit 865cea40b69741c3da2574176876463233b2b67c ]
If the user is requesting us to change the QP state to the same state
that it is already in, return success instead of failure.
Signed-off-by: Ram Amrani <Ram.Amrani(a)cavium.com>
Signed-off-by: Michal Kalderon <Michal.Kalderon(a)cavium.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/qedr/verbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/qedr/verbs.c
+++ b/drivers/infiniband/hw/qedr/verbs.c
@@ -1653,7 +1653,7 @@ static int qedr_update_qp_state(struct q
int status = 0;
if (new_state == qp->state)
- return 1;
+ return 0;
switch (qp->state) {
case QED_ROCE_QP_STATE_RESET:
Patches currently in stable-queue which might be from Ram.Amrani(a)Cavium.com are
queue-4.9/rdma-qedr-return-success-when-not-changing-qp-state.patch
queue-4.9/rdma-qedr-fix-rdma-cm-loopback.patch
This is a note to let you know that I've just added the patch titled
RDMA/qedr: Fix RDMA CM loopback
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:
rdma-qedr-fix-rdma-cm-loopback.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ram Amrani <Ram.Amrani(a)Cavium.com>
Date: Tue, 24 Jan 2017 13:51:41 +0200
Subject: RDMA/qedr: Fix RDMA CM loopback
From: Ram Amrani <Ram.Amrani(a)Cavium.com>
[ Upstream commit af2b14b8b8ae21b0047a52c767ac8b44f435a280 ]
The loopback logic in RDMA CM packets compares Ethernet addresses and
was accidently inverse.
Signed-off-by: Ram Amrani <Ram.Amrani(a)cavium.com>
Signed-off-by: Ariel Elior <Ariel.Elior(a)cavium.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/qedr/qedr_cm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/hw/qedr/qedr_cm.c
+++ b/drivers/infiniband/hw/qedr/qedr_cm.c
@@ -404,9 +404,9 @@ static inline int qedr_gsi_build_packet(
}
if (ether_addr_equal(udh.eth.smac_h, udh.eth.dmac_h))
- packet->tx_dest = QED_ROCE_LL2_TX_DEST_NW;
- else
packet->tx_dest = QED_ROCE_LL2_TX_DEST_LB;
+ else
+ packet->tx_dest = QED_ROCE_LL2_TX_DEST_NW;
packet->roce_mode = roce_mode;
memcpy(packet->header.vaddr, ud_header_buffer, header_size);
Patches currently in stable-queue which might be from Ram.Amrani(a)Cavium.com are
queue-4.9/rdma-qedr-return-success-when-not-changing-qp-state.patch
queue-4.9/rdma-qedr-fix-rdma-cm-loopback.patch
This is a note to let you know that I've just added the patch titled
ravb: Remove Rx overflow log messages
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:
ravb-remove-rx-overflow-log-messages.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Kazuya Mizuguchi <kazuya.mizuguchi.ks(a)renesas.com>
Date: Thu, 12 Jan 2017 13:21:06 +0100
Subject: ravb: Remove Rx overflow log messages
From: Kazuya Mizuguchi <kazuya.mizuguchi.ks(a)renesas.com>
[ Upstream commit 18a3ed59d09cf81a6447aadf6931bf0c9ffec5e0 ]
Remove Rx overflow log messages as in an environment where logging results
in network traffic logging may cause further overflows.
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks(a)renesas.com>
[simon: reworked changelog]
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/renesas/ravb_main.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -941,14 +941,10 @@ static int ravb_poll(struct napi_struct
/* Receive error message handling */
priv->rx_over_errors = priv->stats[RAVB_BE].rx_over_errors;
priv->rx_over_errors += priv->stats[RAVB_NC].rx_over_errors;
- if (priv->rx_over_errors != ndev->stats.rx_over_errors) {
+ if (priv->rx_over_errors != ndev->stats.rx_over_errors)
ndev->stats.rx_over_errors = priv->rx_over_errors;
- netif_err(priv, rx_err, ndev, "Receive Descriptor Empty\n");
- }
- if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors) {
+ if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors)
ndev->stats.rx_fifo_errors = priv->rx_fifo_errors;
- netif_err(priv, rx_err, ndev, "Receive FIFO Overflow\n");
- }
out:
return budget - quota;
}
Patches currently in stable-queue which might be from kazuya.mizuguchi.ks(a)renesas.com are
queue-4.9/ravb-remove-rx-overflow-log-messages.patch
This is a note to let you know that I've just added the patch titled
qla2xxx: Fix wrong IOCB type assumption
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:
qla2xxx-fix-wrong-iocb-type-assumption.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Fri, 23 Dec 2016 18:06:05 -0800
Subject: qla2xxx: Fix wrong IOCB type assumption
From: Quinn Tran <quinn.tran(a)cavium.com>
[ Upstream commit bb1181c9a8b46b6f10e749d9ed94480336445d7f ]
qlt_reset is called with Immedidate Notify IOCB only.
Current code wrongly cast it as ATIO IOCB.
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Bart Van Assche <bart.vanassche(a)sandisk.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_target.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -668,11 +668,9 @@ static int qlt_reset(struct scsi_qla_hos
{
struct qla_hw_data *ha = vha->hw;
struct qla_tgt_sess *sess = NULL;
- uint32_t unpacked_lun, lun = 0;
uint16_t loop_id;
int res = 0;
struct imm_ntfy_from_isp *n = (struct imm_ntfy_from_isp *)iocb;
- struct atio_from_isp *a = (struct atio_from_isp *)iocb;
unsigned long flags;
loop_id = le16_to_cpu(n->u.isp24.nport_handle);
@@ -725,11 +723,7 @@ static int qlt_reset(struct scsi_qla_hos
"loop_id %d)\n", vha->host_no, sess, sess->port_name,
mcmd, loop_id);
- lun = a->u.isp24.fcp_cmnd.lun;
- unpacked_lun = scsilun_to_int((struct scsi_lun *)&lun);
-
- return qlt_issue_task_mgmt(sess, unpacked_lun, mcmd,
- iocb, QLA24XX_MGMT_SEND_NACK);
+ return qlt_issue_task_mgmt(sess, 0, mcmd, iocb, QLA24XX_MGMT_SEND_NACK);
}
/* ha->tgt.sess_lock supposed to be held on entry */
Patches currently in stable-queue which might be from quinn.tran(a)cavium.com are
queue-4.9/qla2xxx-fix-wrong-iocb-type-assumption.patch
This is a note to let you know that I've just added the patch titled
powerpc/mm: Fix memory hotplug BUG() on radix
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:
powerpc-mm-fix-memory-hotplug-bug-on-radix.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Reza Arbab <arbab(a)linux.vnet.ibm.com>
Date: Tue, 3 Jan 2017 14:39:51 -0600
Subject: powerpc/mm: Fix memory hotplug BUG() on radix
From: Reza Arbab <arbab(a)linux.vnet.ibm.com>
[ Upstream commit 32b53c012e0bfe20b2745962a89db0dc72ef3270 ]
Memory hotplug is leading to hash page table calls, even on radix:
arch_add_memory
create_section_mapping
htab_bolt_mapping
BUG_ON(!ppc_md.hpte_insert);
To fix, refactor {create,remove}_section_mapping() into hash__ and
radix__ variants. Leave the radix versions stubbed for now.
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com>
Acked-by: Balbir Singh <bsingharora(a)gmail.com>
Signed-off-by: Reza Arbab <arbab(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/book3s/64/hash.h | 4 ++++
arch/powerpc/mm/hash_utils_64.c | 4 ++--
arch/powerpc/mm/pgtable-book3s64.c | 18 ++++++++++++++++++
3 files changed, 24 insertions(+), 2 deletions(-)
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -201,6 +201,10 @@ extern int __meminit hash__vmemmap_creat
unsigned long phys);
extern void hash__vmemmap_remove_mapping(unsigned long start,
unsigned long page_size);
+
+int hash__create_section_mapping(unsigned long start, unsigned long end);
+int hash__remove_section_mapping(unsigned long start, unsigned long end);
+
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_BOOK3S_64_HASH_H */
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -747,7 +747,7 @@ static unsigned long __init htab_get_tab
}
#ifdef CONFIG_MEMORY_HOTPLUG
-int create_section_mapping(unsigned long start, unsigned long end)
+int hash__create_section_mapping(unsigned long start, unsigned long end)
{
int rc = htab_bolt_mapping(start, end, __pa(start),
pgprot_val(PAGE_KERNEL), mmu_linear_psize,
@@ -761,7 +761,7 @@ int create_section_mapping(unsigned long
return rc;
}
-int remove_section_mapping(unsigned long start, unsigned long end)
+int hash__remove_section_mapping(unsigned long start, unsigned long end)
{
int rc = htab_remove_mapping(start, end, mmu_linear_psize,
mmu_kernel_ssize);
--- a/arch/powerpc/mm/pgtable-book3s64.c
+++ b/arch/powerpc/mm/pgtable-book3s64.c
@@ -125,3 +125,21 @@ void mmu_cleanup_all(void)
else if (mmu_hash_ops.hpte_clear_all)
mmu_hash_ops.hpte_clear_all();
}
+
+#ifdef CONFIG_MEMORY_HOTPLUG
+int create_section_mapping(unsigned long start, unsigned long end)
+{
+ if (radix_enabled())
+ return -ENODEV;
+
+ return hash__create_section_mapping(start, end);
+}
+
+int remove_section_mapping(unsigned long start, unsigned long end)
+{
+ if (radix_enabled())
+ return -ENODEV;
+
+ return hash__remove_section_mapping(start, end);
+}
+#endif /* CONFIG_MEMORY_HOTPLUG */
Patches currently in stable-queue which might be from arbab(a)linux.vnet.ibm.com are
queue-4.9/powerpc-mm-fix-memory-hotplug-bug-on-radix.patch
This is a note to let you know that I've just added the patch titled
perf/x86/intel: Account interrupts for PEBS errors
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:
perf-x86-intel-account-interrupts-for-pebs-errors.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Jiri Olsa <jolsa(a)kernel.org>
Date: Wed, 28 Dec 2016 14:31:03 +0100
Subject: perf/x86/intel: Account interrupts for PEBS errors
From: Jiri Olsa <jolsa(a)kernel.org>
[ Upstream commit 475113d937adfd150eb82b5e2c5507125a68e7af ]
It's possible to set up PEBS events to get only errors and not
any data, like on SNB-X (model 45) and IVB-EP (model 62)
via 2 perf commands running simultaneously:
taskset -c 1 ./perf record -c 4 -e branches:pp -j any -C 10
This leads to a soft lock up, because the error path of the
intel_pmu_drain_pebs_nhm() does not account event->hw.interrupt
for error PEBS interrupts, so in case you're getting ONLY
errors you don't have a way to stop the event when it's over
the max_samples_per_tick limit:
NMI watchdog: BUG: soft lockup - CPU#22 stuck for 22s! [perf_fuzzer:5816]
...
RIP: 0010:[<ffffffff81159232>] [<ffffffff81159232>] smp_call_function_single+0xe2/0x140
...
Call Trace:
? trace_hardirqs_on_caller+0xf5/0x1b0
? perf_cgroup_attach+0x70/0x70
perf_install_in_context+0x199/0x1b0
? ctx_resched+0x90/0x90
SYSC_perf_event_open+0x641/0xf90
SyS_perf_event_open+0x9/0x10
do_syscall_64+0x6c/0x1f0
entry_SYSCALL64_slow_path+0x25/0x25
Add perf_event_account_interrupt() which does the interrupt
and frequency checks and call it from intel_pmu_drain_pebs_nhm()'s
error path.
We keep the pending_kill and pending_wakeup logic only in the
__perf_event_overflow() path, because they make sense only if
there's any data to deliver.
Signed-off-by: Jiri Olsa <jolsa(a)kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Vince Weaver <vince(a)deater.net>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Link: http://lkml.kernel.org/r/1482931866-6018-2-git-send-email-jolsa@kernel.org
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/events/intel/ds.c | 6 ++++-
include/linux/perf_event.h | 1
kernel/events/core.c | 47 +++++++++++++++++++++++++++++----------------
3 files changed, 37 insertions(+), 17 deletions(-)
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1389,9 +1389,13 @@ static void intel_pmu_drain_pebs_nhm(str
continue;
/* log dropped samples number */
- if (error[bit])
+ if (error[bit]) {
perf_log_lost_samples(event, error[bit]);
+ if (perf_event_account_interrupt(event))
+ x86_pmu_stop(event, 0);
+ }
+
if (counts[bit]) {
__intel_pmu_pebs_event(event, iregs, base,
top, bit, counts[bit]);
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1259,6 +1259,7 @@ extern void perf_event_disable(struct pe
extern void perf_event_disable_local(struct perf_event *event);
extern void perf_event_disable_inatomic(struct perf_event *event);
extern void perf_event_task_tick(void);
+extern int perf_event_account_interrupt(struct perf_event *event);
#else /* !CONFIG_PERF_EVENTS: */
static inline void *
perf_aux_output_begin(struct perf_output_handle *handle,
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7088,25 +7088,12 @@ static void perf_log_itrace_start(struct
perf_output_end(&handle);
}
-/*
- * Generic event overflow handling, sampling.
- */
-
-static int __perf_event_overflow(struct perf_event *event,
- int throttle, struct perf_sample_data *data,
- struct pt_regs *regs)
+static int
+__perf_event_account_interrupt(struct perf_event *event, int throttle)
{
- int events = atomic_read(&event->event_limit);
struct hw_perf_event *hwc = &event->hw;
- u64 seq;
int ret = 0;
-
- /*
- * Non-sampling counters might still use the PMI to fold short
- * hardware counters, ignore those.
- */
- if (unlikely(!is_sampling_event(event)))
- return 0;
+ u64 seq;
seq = __this_cpu_read(perf_throttled_seq);
if (seq != hwc->interrupts_seq) {
@@ -7134,6 +7121,34 @@ static int __perf_event_overflow(struct
perf_adjust_period(event, delta, hwc->last_period, true);
}
+ return ret;
+}
+
+int perf_event_account_interrupt(struct perf_event *event)
+{
+ return __perf_event_account_interrupt(event, 1);
+}
+
+/*
+ * Generic event overflow handling, sampling.
+ */
+
+static int __perf_event_overflow(struct perf_event *event,
+ int throttle, struct perf_sample_data *data,
+ struct pt_regs *regs)
+{
+ int events = atomic_read(&event->event_limit);
+ int ret = 0;
+
+ /*
+ * Non-sampling counters might still use the PMI to fold short
+ * hardware counters, ignore those.
+ */
+ if (unlikely(!is_sampling_event(event)))
+ return 0;
+
+ ret = __perf_event_account_interrupt(event, throttle);
+
/*
* XXX event_limit might not quite work as expected on inherited
* events
Patches currently in stable-queue which might be from jolsa(a)kernel.org are
queue-4.9/perf-test-attr-fix-ignored-test-case-result.patch
queue-4.9/perf-x86-intel-account-interrupts-for-pebs-errors.patch
queue-4.9/tools-include-do-not-use-poison-with-c.patch
This is a note to let you know that I've just added the patch titled
perf test attr: Fix ignored test case result
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:
perf-test-attr-fix-ignored-test-case-result.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
Date: Wed, 13 Sep 2017 10:12:09 +0200
Subject: perf test attr: Fix ignored test case result
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
[ Upstream commit 22905582f6dd4bbd0c370fe5732c607452010c04 ]
Command perf test -v 16 (Setup struct perf_event_attr test) always
reports success even if the test case fails. It works correctly if you
also specify -F (for don't fork).
root@s35lp76 perf]# ./perf test -v 16
15: Setup struct perf_event_attr :
--- start ---
running './tests/attr/test-record-no-delay'
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB /tmp/tmp4E1h7R/perf.data
(1 samples) ]
expected task=0, got 1
expected precise_ip=0, got 3
expected wakeup_events=1, got 0
FAILED './tests/attr/test-record-no-delay' - match failure
test child finished with 0
---- end ----
Setup struct perf_event_attr: Ok
The reason for the wrong error reporting is the return value of the
system() library call. It is called in run_dir() file tests/attr.c and
returns the exit status, in above case 0xff00.
This value is given as parameter to the exit() function which can only
handle values 0-0xff.
The child process terminates with exit value of 0 and the parent does
not detect any error.
This patch corrects the error reporting and prints the correct test
result.
Signed-off-by: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Cc: Hendrik Brueckner <brueckner(a)linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Cc: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
LPU-Reference: 20170913081209.39570-2-tmricht(a)linux.vnet.ibm.com
Link: http://lkml.kernel.org/n/tip-rdube6rfcjsr1nzue72c7lqn@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/tests/attr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -150,7 +150,7 @@ static int run_dir(const char *d, const
snprintf(cmd, 3*PATH_MAX, PYTHON " %s/attr.py -d %s/attr/ -p %s %.*s",
d, d, perf, vcnt, v);
- return system(cmd);
+ return system(cmd) ? TEST_FAIL : TEST_OK;
}
int test__attr(int subtest __maybe_unused)
Patches currently in stable-queue which might be from tmricht(a)linux.vnet.ibm.com are
queue-4.9/perf-test-attr-fix-ignored-test-case-result.patch
This is a note to let you know that I've just added the patch titled
nvmet: cancel fatal error and flush async work before free controller
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:
nvmet-cancel-fatal-error-and-flush-async-work-before-free-controller.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Sagi Grimberg <sagi(a)grimberg.me>
Date: Sun, 1 Jan 2017 13:41:56 +0200
Subject: nvmet: cancel fatal error and flush async work before free controller
From: Sagi Grimberg <sagi(a)grimberg.me>
[ Upstream commit 06406d81a2d7cfb8abcc4fa6cdfeb8e5897007c5 ]
Make sure they are not running and we can free the controller
safely.
Signed-off-by: Roy Shterman <roys(a)lightbitslabs.com>
Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/target/core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/nvme/target/core.c
+++ b/drivers/nvme/target/core.c
@@ -816,6 +816,9 @@ static void nvmet_ctrl_free(struct kref
list_del(&ctrl->subsys_entry);
mutex_unlock(&subsys->lock);
+ flush_work(&ctrl->async_event_work);
+ cancel_work_sync(&ctrl->fatal_err_work);
+
ida_simple_remove(&subsys->cntlid_ida, ctrl->cntlid);
nvmet_subsys_put(subsys);
Patches currently in stable-queue which might be from sagi(a)grimberg.me are
queue-4.9/nvmet-cancel-fatal-error-and-flush-async-work-before-free-controller.patch
This is a note to let you know that I've just added the patch titled
NFSv4: Fix client recovery when server reboots multiple times
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:
nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Fri, 13 Jan 2017 13:31:32 -0500
Subject: NFSv4: Fix client recovery when server reboots multiple times
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit c6180a6237174f481dc856ed6e890d8196b6f0fb ]
If the server reboots multiple times, the client should rely on the
server to tell it that it cannot reclaim state as per section 9.6.3.4
in RFC7530 and section 8.4.2.1 in RFC5661.
Currently, the client is being to conservative, and is assuming that
if the server reboots while state recovery is in progress, then it must
ignore state that was not recovered before the reboot.
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4state.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -1718,7 +1718,6 @@ static int nfs4_recovery_handle_error(st
break;
case -NFS4ERR_STALE_CLIENTID:
set_bit(NFS4CLNT_LEASE_EXPIRED, &clp->cl_state);
- nfs4_state_clear_reclaim_reboot(clp);
nfs4_state_start_reclaim_reboot(clp);
break;
case -NFS4ERR_EXPIRED:
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.9/nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch
queue-4.9/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
This is a note to let you know that I've just added the patch titled
nfs: Don't take a reference on fl->fl_file for LOCK operation
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:
nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Benjamin Coddington <bcodding(a)redhat.com>
Date: Thu, 5 Jan 2017 10:20:16 -0500
Subject: nfs: Don't take a reference on fl->fl_file for LOCK operation
From: Benjamin Coddington <bcodding(a)redhat.com>
[ Upstream commit 4b09ec4b14a168bf2c687e1f598140c3c11e9222 ]
I have reports of a crash that look like __fput() was called twice for
a NFSv4.0 file. It seems possible that the state manager could try to
reclaim a lock and take a reference on the fl->fl_file at the same time the
file is being released if, during the close(), a signal interrupts the wait
for outstanding IO while removing locks which then skips the removal
of that lock.
Since 83bfff23e9ed ("nfs4: have do_vfs_lock take an inode pointer") has
removed the need to traverse fl->fl_file->f_inode in nfs4_lock_done(),
taking that reference is no longer necessary.
Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com>
Reviewed-by: Jeff Layton <jlayton(a)redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4proc.c | 3 ---
1 file changed, 3 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -38,7 +38,6 @@
#include <linux/mm.h>
#include <linux/delay.h>
#include <linux/errno.h>
-#include <linux/file.h>
#include <linux/string.h>
#include <linux/ratelimit.h>
#include <linux/printk.h>
@@ -6006,7 +6005,6 @@ static struct nfs4_lockdata *nfs4_alloc_
p->server = server;
atomic_inc(&lsp->ls_count);
p->ctx = get_nfs_open_context(ctx);
- get_file(fl->fl_file);
memcpy(&p->fl, fl, sizeof(p->fl));
return p;
out_free_seqid:
@@ -6119,7 +6117,6 @@ static void nfs4_lock_release(void *call
nfs_free_seqid(data->arg.lock_seqid);
nfs4_put_lock_state(data->lsp);
put_nfs_open_context(data->ctx);
- fput(data->fl.fl_file);
kfree(data);
dprintk("%s: done!\n", __func__);
}
Patches currently in stable-queue which might be from bcodding(a)redhat.com are
queue-4.9/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
This is a note to let you know that I've just added the patch titled
net: thunderx: avoid dereferencing xcv when NULL
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:
net-thunderx-avoid-dereferencing-xcv-when-null.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Vincent <vincent.stehle(a)laposte.net>
Date: Mon, 30 Jan 2017 15:06:43 +0100
Subject: net: thunderx: avoid dereferencing xcv when NULL
From: Vincent <vincent.stehle(a)laposte.net>
[ Upstream commit c73e44269369e936165f0f9b61f1f09a11dae01c ]
This fixes the following smatch and coccinelle warnings:
drivers/net/ethernet/cavium/thunder/thunder_xcv.c:119 xcv_setup_link() error: we previously assumed 'xcv' could be null (see line 118) [smatch]
drivers/net/ethernet/cavium/thunder/thunder_xcv.c:119:16-20: ERROR: xcv is NULL but dereferenced. [coccinelle]
Fixes: 6465859aba1e66a5 ("net: thunderx: Add RGMII interface type support")
Signed-off-by: Vincent Stehlé <vincent.stehle(a)laposte.net>
Cc: Sunil Goutham <sgoutham(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/cavium/thunder/thunder_xcv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/ethernet/cavium/thunder/thunder_xcv.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_xcv.c
@@ -116,8 +116,7 @@ void xcv_setup_link(bool link_up, int li
int speed = 2;
if (!xcv) {
- dev_err(&xcv->pdev->dev,
- "XCV init not done, probe may have failed\n");
+ pr_err("XCV init not done, probe may have failed\n");
return;
}
Patches currently in stable-queue which might be from vincent.stehle(a)laposte.net are
queue-4.9/net-thunderx-avoid-dereferencing-xcv-when-null.patch
This is a note to let you know that I've just added the patch titled
net: systemport: Utilize skb_put_padto()
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:
net-systemport-utilize-skb_put_padto.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Tue, 3 Jan 2017 16:34:48 -0800
Subject: net: systemport: Utilize skb_put_padto()
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit bb7da333d0a9f3bddc08f84187b7579a3f68fd24 ]
Since we need to pad our packets, utilize skb_put_padto() which
increases skb->len by how much we need to pad, allowing us to eliminate
the test on skb->len right below.
Signed-off-by: Florian Fainelli <f.fainelli(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/net/ethernet/broadcom/bcmsysport.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1039,13 +1039,12 @@ static netdev_tx_t bcm_sysport_xmit(stru
* (including FCS and tag) because the length verification is done after
* the Broadcom tag is stripped off the ingress packet.
*/
- if (skb_padto(skb, ETH_ZLEN + ENET_BRCM_TAG_LEN)) {
+ if (skb_put_padto(skb, ETH_ZLEN + ENET_BRCM_TAG_LEN)) {
ret = NETDEV_TX_OK;
goto out;
}
- skb_len = skb->len < ETH_ZLEN + ENET_BRCM_TAG_LEN ?
- ETH_ZLEN + ENET_BRCM_TAG_LEN : skb->len;
+ skb_len = skb->len;
mapping = dma_map_single(kdev, skb->data, skb_len, DMA_TO_DEVICE);
if (dma_mapping_error(kdev, mapping)) {
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.9/net-systemport-pad-packet-before-inserting-tsb.patch
queue-4.9/net-systemport-utilize-skb_put_padto.patch
queue-4.9/net-phy-micrel-ksz8795-do-not-set-supported_pause.patch
This is a note to let you know that I've just added the patch titled
net: systemport: Pad packet before inserting TSB
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:
net-systemport-pad-packet-before-inserting-tsb.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Tue, 3 Jan 2017 16:34:49 -0800
Subject: net: systemport: Pad packet before inserting TSB
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit 38e5a85562a6cd911fc26d951d576551a688574c ]
Inserting the TSB means adding an extra 8 bytes in front the of packet
that is going to be used as metadata information by the TDMA engine, but
stripped off, so it does not really help with the packet padding.
For some odd packet sizes that fall below the 60 bytes payload (e.g: ARP)
we can end-up padding them after the TSB insertion, thus making them 64
bytes, but with the TDMA stripping off the first 8 bytes, they could
still be smaller than 64 bytes which is required to ingress the switch.
Fix this by swapping the padding and TSB insertion, guaranteeing that
the packets have the right sizes.
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Florian Fainelli <f.fainelli(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/net/ethernet/broadcom/bcmsysport.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1023,15 +1023,6 @@ static netdev_tx_t bcm_sysport_xmit(stru
goto out;
}
- /* Insert TSB and checksum infos */
- if (priv->tsb_en) {
- skb = bcm_sysport_insert_tsb(skb, dev);
- if (!skb) {
- ret = NETDEV_TX_OK;
- goto out;
- }
- }
-
/* The Ethernet switch we are interfaced with needs packets to be at
* least 64 bytes (including FCS) otherwise they will be discarded when
* they enter the switch port logic. When Broadcom tags are enabled, we
@@ -1044,6 +1035,15 @@ static netdev_tx_t bcm_sysport_xmit(stru
goto out;
}
+ /* Insert TSB and checksum infos */
+ if (priv->tsb_en) {
+ skb = bcm_sysport_insert_tsb(skb, dev);
+ if (!skb) {
+ ret = NETDEV_TX_OK;
+ goto out;
+ }
+ }
+
skb_len = skb->len;
mapping = dma_map_single(kdev, skb->data, skb_len, DMA_TO_DEVICE);
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.9/net-systemport-pad-packet-before-inserting-tsb.patch
queue-4.9/net-systemport-utilize-skb_put_padto.patch
queue-4.9/net-phy-micrel-ksz8795-do-not-set-supported_pause.patch
This is a note to let you know that I've just added the patch titled
net: sctp: fix array overrun read on sctp_timer_tbl
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:
net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 20 Jan 2017 13:01:57 +0000
Subject: net: sctp: fix array overrun read on sctp_timer_tbl
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 0e73fc9a56f22f2eec4d2b2910c649f7af67b74d ]
The comparison on the timeout can lead to an array overrun
read on sctp_timer_tbl because of an off-by-one error. Fix
this by using < instead of <= and also compare to the array
size rather than SCTP_EVENT_TIMEOUT_MAX.
Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
Signed-off-by: Colin Ian King <colin.king(a)canonical.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>
---
net/sctp/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sctp/debug.c
+++ b/net/sctp/debug.c
@@ -166,7 +166,7 @@ static const char *const sctp_timer_tbl[
/* Lookup timer debug name. */
const char *sctp_tname(const sctp_subtype_t id)
{
- if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
+ if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
return sctp_timer_tbl[id.timeout];
return "unknown_timer";
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.9/staging-rtl8188eu-avoid-a-null-dereference-on-pmlmepriv.patch
queue-4.9/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
This is a note to let you know that I've just added the patch titled
net: qrtr: Mark 'buf' as little endian
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:
net-qrtr-mark-buf-as-little-endian.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Stephen Boyd <sboyd(a)codeaurora.org>
Date: Mon, 9 Jan 2017 14:31:58 -0800
Subject: net: qrtr: Mark 'buf' as little endian
From: Stephen Boyd <sboyd(a)codeaurora.org>
[ Upstream commit 3512a1ad56174308a9fd3e10f4b1e3e152e9ec01 ]
Failure to mark this pointer as __le32 causes checkers like
sparse to complain:
net/qrtr/qrtr.c:274:16: warning: incorrect type in assignment (different base types)
net/qrtr/qrtr.c:274:16: expected unsigned int [unsigned] [usertype] <noident>
net/qrtr/qrtr.c:274:16: got restricted __le32 [usertype] <noident>
net/qrtr/qrtr.c:275:16: warning: incorrect type in assignment (different base types)
net/qrtr/qrtr.c:275:16: expected unsigned int [unsigned] [usertype] <noident>
net/qrtr/qrtr.c:275:16: got restricted __le32 [usertype] <noident>
net/qrtr/qrtr.c:276:16: warning: incorrect type in assignment (different base types)
net/qrtr/qrtr.c:276:16: expected unsigned int [unsigned] [usertype] <noident>
net/qrtr/qrtr.c:276:16: got restricted __le32 [usertype] <noident>
Silence it.
Cc: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
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>
---
net/qrtr/qrtr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -252,7 +252,7 @@ static struct sk_buff *qrtr_alloc_resume
const int pkt_len = 20;
struct qrtr_hdr *hdr;
struct sk_buff *skb;
- u32 *buf;
+ __le32 *buf;
skb = alloc_skb(QRTR_HDR_SIZE + pkt_len, GFP_KERNEL);
if (!skb)
@@ -269,7 +269,7 @@ static struct sk_buff *qrtr_alloc_resume
hdr->dst_node_id = cpu_to_le32(dst_node);
hdr->dst_port_id = cpu_to_le32(QRTR_PORT_CTRL);
- buf = (u32 *)skb_put(skb, pkt_len);
+ buf = (__le32 *)skb_put(skb, pkt_len);
memset(buf, 0, pkt_len);
buf[0] = cpu_to_le32(QRTR_TYPE_RESUME_TX);
buf[1] = cpu_to_le32(src_node);
Patches currently in stable-queue which might be from sboyd(a)codeaurora.org are
queue-4.9/net-qrtr-mark-buf-as-little-endian.patch
This is a note to let you know that I've just added the patch titled
net: phy: micrel: KSZ8795 do not set SUPPORTED_[Asym_]Pause
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:
net-phy-micrel-ksz8795-do-not-set-supported_pause.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Sean Nyekjaer <sean.nyekjaer(a)prevas.dk>
Date: Fri, 27 Jan 2017 21:39:03 +0100
Subject: net: phy: micrel: KSZ8795 do not set SUPPORTED_[Asym_]Pause
From: Sean Nyekjaer <sean.nyekjaer(a)prevas.dk>
[ Upstream commit cf626c3b252b2c9d131be0dd66096ec3bf729e54 ]
As pr commit "net: phy: phy drivers should not set SUPPORTED_[Asym_]Pause"
this phy driver should not set these feature bits.
Signed-off-by: Sean Nyekjaer <sean.nyekjaer(a)prevas.dk>
Fixes: 9d162ed69f51 ("net: phy: micrel: add support for KSZ8795")
Reviewed-by: Florian Fainelli <f.fainelli(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/net/phy/micrel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -1020,7 +1020,7 @@ static struct phy_driver ksphy_driver[]
.phy_id = PHY_ID_KSZ8795,
.phy_id_mask = MICREL_PHY_ID_MASK,
.name = "Micrel KSZ8795",
- .features = (SUPPORTED_Pause | SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = kszphy_config_init,
.config_aneg = ksz8873mll_config_aneg,
Patches currently in stable-queue which might be from sean.nyekjaer(a)prevas.dk are
queue-4.9/net-phy-micrel-ksz8795-do-not-set-supported_pause.patch
This is a note to let you know that I've just added the patch titled
net/mlx4_en: Fix type mismatch for 32-bit systems
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:
net-mlx4_en-fix-type-mismatch-for-32-bit-systems.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Slava Shwartsman <slavash(a)mellanox.com>
Date: Thu, 29 Dec 2016 18:37:12 +0200
Subject: net/mlx4_en: Fix type mismatch for 32-bit systems
From: Slava Shwartsman <slavash(a)mellanox.com>
[ Upstream commit 61b6034c6cfdcb265bb453505c3d688e7567727a ]
is_power_of_2 expects unsigned long and we pass u64 max_val_cycles,
this will be truncated on 32 bit systems, and the result is not what we
were expecting.
div_u64 expects u32 as a second argument and we pass
max_val_cycles_rounded which is u64 hence it will always be truncated.
Fix was tested on both 64 and 32 bit systems and got same results for
max_val_cycles and max_val_cycles_rounded.
Fixes: 4850cf458157 ("net/mlx4_en: Resolve dividing by zero in 32-bit system")
Signed-off-by: Slava Shwartsman <slavash(a)mellanox.com>
Signed-off-by: Tariq Toukan <tariqt(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx4/en_clock.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx4/en_clock.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
@@ -251,13 +251,9 @@ static u32 freq_to_shift(u16 freq)
{
u32 freq_khz = freq * 1000;
u64 max_val_cycles = freq_khz * 1000 * MLX4_EN_WRAP_AROUND_SEC;
- u64 tmp_rounded =
- roundup_pow_of_two(max_val_cycles) > max_val_cycles ?
- roundup_pow_of_two(max_val_cycles) - 1 : UINT_MAX;
- u64 max_val_cycles_rounded = is_power_of_2(max_val_cycles + 1) ?
- max_val_cycles : tmp_rounded;
+ u64 max_val_cycles_rounded = 1ULL << fls64(max_val_cycles - 1);
/* calculate max possible multiplier in order to fit in 64bit */
- u64 max_mul = div_u64(0xffffffffffffffffULL, max_val_cycles_rounded);
+ u64 max_mul = div64_u64(ULLONG_MAX, max_val_cycles_rounded);
/* This comes from the reverse of clocksource_khz2mult */
return ilog2(div_u64(max_mul * freq_khz, 1000000));
Patches currently in stable-queue which might be from slavash(a)mellanox.com are
queue-4.9/net-mlx4_en-fix-type-mismatch-for-32-bit-systems.patch
This is a note to let you know that I've just added the patch titled
net: fec: fix multicast filtering hardware setup
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:
net-fec-fix-multicast-filtering-hardware-setup.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Rui Sousa <rui.sousa(a)nxp.com>
Date: Mon, 13 Feb 2017 10:01:25 +0800
Subject: net: fec: fix multicast filtering hardware setup
From: Rui Sousa <rui.sousa(a)nxp.com>
[ Upstream commit 01f8902bcf3ff124d0aeb88a774180ebcec20ace ]
Fix hardware setup of multicast address hash:
- Never clear the hardware hash (to avoid packet loss)
- Construct the hash register values in software and then write once
to hardware
Signed-off-by: Rui Sousa <rui.sousa(a)nxp.com>
Signed-off-by: Fugang Duan <fugang.duan(a)nxp.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/fec_main.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2923,6 +2923,7 @@ static void set_multicast_list(struct ne
struct netdev_hw_addr *ha;
unsigned int i, bit, data, crc, tmp;
unsigned char hash;
+ unsigned int hash_high = 0, hash_low = 0;
if (ndev->flags & IFF_PROMISC) {
tmp = readl(fep->hwp + FEC_R_CNTRL);
@@ -2945,11 +2946,7 @@ static void set_multicast_list(struct ne
return;
}
- /* Clear filter and add the addresses in hash register
- */
- writel(0, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- writel(0, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
-
+ /* Add the addresses in hash register */
netdev_for_each_mc_addr(ha, ndev) {
/* calculate crc32 value of mac address */
crc = 0xffffffff;
@@ -2967,16 +2964,14 @@ static void set_multicast_list(struct ne
*/
hash = (crc >> (32 - FEC_HASH_BITS)) & 0x3f;
- if (hash > 31) {
- tmp = readl(fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- tmp |= 1 << (hash - 32);
- writel(tmp, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- } else {
- tmp = readl(fep->hwp + FEC_GRP_HASH_TABLE_LOW);
- tmp |= 1 << hash;
- writel(tmp, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
- }
+ if (hash > 31)
+ hash_high |= 1 << (hash - 32);
+ else
+ hash_low |= 1 << hash;
}
+
+ writel(hash_high, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
+ writel(hash_low, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
}
/* Set a MAC change in hardware. */
Patches currently in stable-queue which might be from rui.sousa(a)nxp.com are
queue-4.9/net-fec-fix-multicast-filtering-hardware-setup.patch
This is a note to let you know that I've just added the patch titled
net/appletalk: Fix kernel memory disclosure
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:
net-appletalk-fix-kernel-memory-disclosure.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net>
Date: Mon, 9 Jan 2017 20:57:48 +0700
Subject: net/appletalk: Fix kernel memory disclosure
From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net>
[ Upstream commit ce7e40c432ba84da104438f6799d460a4cad41bc ]
ipddp_route structs contain alignment padding so kernel heap memory
is leaked when they are copied to user space in
ipddp_ioctl(SIOCFINDIPDDPRT). Change kmalloc() to kzalloc() to clear
that memory.
Signed-off-by: Vlad Tsyrklevich <vlad(a)tsyrklevich.net>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/appletalk/ipddp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/appletalk/ipddp.c
+++ b/drivers/net/appletalk/ipddp.c
@@ -191,7 +191,7 @@ static netdev_tx_t ipddp_xmit(struct sk_
*/
static int ipddp_create(struct ipddp_route *new_rt)
{
- struct ipddp_route *rt = kmalloc(sizeof(*rt), GFP_KERNEL);
+ struct ipddp_route *rt = kzalloc(sizeof(*rt), GFP_KERNEL);
if (rt == NULL)
return -ENOMEM;
Patches currently in stable-queue which might be from vlad(a)tsyrklevich.net are
queue-4.9/net-appletalk-fix-kernel-memory-disclosure.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-msm: fix issue with power irq
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:
mmc-sdhci-msm-fix-issue-with-power-irq.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Subhash Jadavani <subhashj(a)codeaurora.org>
Date: Wed, 27 Sep 2017 11:04:40 +0530
Subject: mmc: sdhci-msm: fix issue with power irq
From: Subhash Jadavani <subhashj(a)codeaurora.org>
[ Upstream commit c7ccee224d2d551f712752c4a16947f6529d6506 ]
SDCC controller reset (SW_RST) during probe may trigger power irq if
previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we
enable the power irq interrupt in GIC (by registering the interrupt
handler), we need to ensure that any pending power irq interrupt status
is acknowledged otherwise power irq interrupt handler would be fired
prematurely.
Signed-off-by: Subhash Jadavani <subhashj(a)codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana(a)codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-msm.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -642,6 +642,21 @@ static int sdhci_msm_probe(struct platfo
CORE_VENDOR_SPEC_CAPABILITIES0);
}
+ /*
+ * Power on reset state may trigger power irq if previous status of
+ * PWRCTL was either BUS_ON or IO_HIGH_V. So before enabling pwr irq
+ * interrupt in GIC, any pending power irq interrupt should be
+ * acknowledged. Otherwise power irq interrupt handler would be
+ * fired prematurely.
+ */
+ sdhci_msm_voltage_switch(host);
+
+ /*
+ * Ensure that above writes are propogated before interrupt enablement
+ * in GIC.
+ */
+ mb();
+
/* Setup IRQ for handling power/voltage tasks with PMIC */
msm_host->pwr_irq = platform_get_irq_byname(pdev, "pwr_irq");
if (msm_host->pwr_irq < 0) {
@@ -651,6 +666,9 @@ static int sdhci_msm_probe(struct platfo
goto clk_disable;
}
+ /* Enable pwr irq interrupts */
+ writel_relaxed(INT_MASK, msm_host->core_mem + CORE_PWRCTL_MASK);
+
ret = devm_request_threaded_irq(&pdev->dev, msm_host->pwr_irq, NULL,
sdhci_msm_pwr_irq, IRQF_ONESHOT,
dev_name(&pdev->dev), host);
Patches currently in stable-queue which might be from subhashj(a)codeaurora.org are
queue-4.9/mmc-sdhci-msm-fix-issue-with-power-irq.patch
This is a note to let you know that I've just added the patch titled
mm: fix remote numa hits statistics
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mm-fix-remote-numa-hits-statistics.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Michal Hocko <mhocko(a)suse.com>
Date: Tue, 10 Jan 2017 16:57:39 -0800
Subject: mm: fix remote numa hits statistics
From: Michal Hocko <mhocko(a)suse.com>
[ Upstream commit 2df26639e708a88dcc22171949da638a9998f3bc ]
Jia He has noticed that commit b9f00e147f27 ("mm, page_alloc: reduce
branches in zone_statistics") has an unintentional side effect that
remote node allocation requests are accounted as NUMA_MISS rathat than
NUMA_HIT and NUMA_OTHER if such a request doesn't use __GFP_OTHER_NODE.
There are many of these potentially because the flag is used very rarely
while we have many users of __alloc_pages_node.
Fix this by simply ignoring __GFP_OTHER_NODE (it can be removed in a
follow up patch) and treat all allocations that were satisfied from the
preferred zone's node as NUMA_HITS because this is the same node we
requested the allocation from in most cases. If this is not the local
node then we just account it as NUMA_OTHER rather than NUMA_LOCAL.
One downsize would be that an allocation request for a node which is
outside of the mempolicy nodemask would be reported as a hit which is a
bit weird but that was the case before b9f00e147f27 already.
Fixes: b9f00e147f27 ("mm, page_alloc: reduce branches in zone_statistics")
Link: http://lkml.kernel.org/r/20170102153057.9451-2-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Jia He <hejianet(a)gmail.com>
Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> # with cbmc[1] superpowers
Acked-by: Mel Gorman <mgorman(a)suse.de>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Cc: Taku Izumi <izumi.taku(a)jp.fujitsu.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>
---
mm/page_alloc.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2592,30 +2592,23 @@ int __isolate_free_page(struct page *pag
* Update NUMA hit/miss statistics
*
* Must be called with interrupts disabled.
- *
- * When __GFP_OTHER_NODE is set assume the node of the preferred
- * zone is the local node. This is useful for daemons who allocate
- * memory on behalf of other processes.
*/
static inline void zone_statistics(struct zone *preferred_zone, struct zone *z,
gfp_t flags)
{
#ifdef CONFIG_NUMA
- int local_nid = numa_node_id();
enum zone_stat_item local_stat = NUMA_LOCAL;
- if (unlikely(flags & __GFP_OTHER_NODE)) {
+ if (z->node != numa_node_id())
local_stat = NUMA_OTHER;
- local_nid = preferred_zone->node;
- }
- if (z->node == local_nid) {
+ if (z->node == preferred_zone->node)
__inc_zone_state(z, NUMA_HIT);
- __inc_zone_state(z, local_stat);
- } else {
+ else {
__inc_zone_state(z, NUMA_MISS);
__inc_zone_state(preferred_zone, NUMA_FOREIGN);
}
+ __inc_zone_state(z, local_stat);
#endif
}
Patches currently in stable-queue which might be from mhocko(a)suse.com are
queue-4.9/mm-fix-remote-numa-hits-statistics.patch
queue-4.9/mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry.patch
This is a note to let you know that I've just added the patch titled
mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers
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-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Wed, 8 Feb 2017 14:30:53 -0800
Subject: mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers
From: Jan Kara <jack(a)suse.cz>
[ Upstream commit 0911d0041c22922228ca52a977d7b0b0159fee4b ]
Some ->page_mkwrite handlers may return VM_FAULT_RETRY as its return
code (GFS2 or Lustre can definitely do this). However VM_FAULT_RETRY
from ->page_mkwrite is completely unhandled by the mm code and results
in locking and writeably mapping the page which definitely is not what
the caller wanted.
Fix Lustre and block_page_mkwrite_ret() used by other filesystems
(notably GFS2) to return VM_FAULT_NOPAGE instead which results in
bailing out from the fault code, the CPU then retries the access, and we
fault again effectively doing what the handler wanted.
Link: http://lkml.kernel.org/r/20170203150729.15863-1-jack@suse.cz
Signed-off-by: Jan Kara <jack(a)suse.cz>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Reviewed-by: Jinshan Xiong <jinshan.xiong(a)intel.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
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/staging/lustre/lustre/llite/llite_mmap.c | 4 +---
include/linux/buffer_head.h | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/staging/lustre/lustre/llite/llite_mmap.c
+++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c
@@ -401,15 +401,13 @@ static int ll_page_mkwrite(struct vm_are
result = VM_FAULT_LOCKED;
break;
case -ENODATA:
+ case -EAGAIN:
case -EFAULT:
result = VM_FAULT_NOPAGE;
break;
case -ENOMEM:
result = VM_FAULT_OOM;
break;
- case -EAGAIN:
- result = VM_FAULT_RETRY;
- break;
default:
result = VM_FAULT_SIGBUS;
break;
--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -239,12 +239,10 @@ static inline int block_page_mkwrite_ret
{
if (err == 0)
return VM_FAULT_LOCKED;
- if (err == -EFAULT)
+ if (err == -EFAULT || err == -EAGAIN)
return VM_FAULT_NOPAGE;
if (err == -ENOMEM)
return VM_FAULT_OOM;
- if (err == -EAGAIN)
- return VM_FAULT_RETRY;
/* -ENOSPC, -EDQUOT, -EIO ... */
return VM_FAULT_SIGBUS;
}
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.9/mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
queue-4.9/dax-avoid-page-invalidation-races-and-unnecessary-radix-tree-traversals.patch
This is a note to let you know that I've just added the patch titled
mac80211: prevent skb/txq mismatch
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:
mac80211-prevent-skb-txq-mismatch.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Michal Kazior <michal.kazior(a)tieto.com>
Date: Fri, 13 Jan 2017 13:32:51 +0100
Subject: mac80211: prevent skb/txq mismatch
From: Michal Kazior <michal.kazior(a)tieto.com>
[ Upstream commit dbef53621116474bb883f76f0ba6b7640bc42332 ]
Station structure is considered as not uploaded
(to driver) until drv_sta_state() finishes. This
call is however done after the structure is
attached to mac80211 internal lists and hashes.
This means mac80211 can lookup (and use) station
structure before it is uploaded to a driver.
If this happens (structure exists, but
sta->uploaded is false) fast_tx path can still be
taken. Deep in the fastpath call the sta->uploaded
is checked against to derive "pubsta" argument for
ieee80211_get_txq(). If sta->uploaded is false
(and sta is actually non-NULL) ieee80211_get_txq()
effectively downgraded to vif->txq.
At first glance this may look innocent but coerces
mac80211 into a state that is almost guaranteed
(codel may drop offending skb) to crash because a
station-oriented skb gets queued up on
vif-oriented txq. The ieee80211_tx_dequeue() ends
up looking at info->control.flags and tries to use
txq->sta which in the fail case is NULL.
It's probably pointless to pretend one can
downgrade skb from sta-txq to vif-txq.
Since downgrading unicast traffic to vif->txq must
not be done there's no txq to put a frame on if
sta->uploaded is false. Therefore the code is made
to fall back to regular tx() op path if the
described condition is hit.
Only drivers using wake_tx_queue were affected.
Example crash dump before fix:
Unable to handle kernel paging request at virtual address ffffe26c
PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
[<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
[<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
[<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
[<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
[<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
[<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
[<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
[<c0572e90>] (net_rx_action+0xac/0x160)
Reported-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior(a)tieto.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/tx.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1244,7 +1244,7 @@ ieee80211_tx_prepare(struct ieee80211_su
static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
struct ieee80211_vif *vif,
- struct ieee80211_sta *pubsta,
+ struct sta_info *sta,
struct sk_buff *skb)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
@@ -1258,10 +1258,13 @@ static struct txq_info *ieee80211_get_tx
if (!ieee80211_is_data(hdr->frame_control))
return NULL;
- if (pubsta) {
+ if (sta) {
u8 tid = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
- txq = pubsta->txq[tid];
+ if (!sta->uploaded)
+ return NULL;
+
+ txq = sta->sta.txq[tid];
} else if (vif) {
txq = vif->txq;
}
@@ -1499,23 +1502,17 @@ static bool ieee80211_queue_skb(struct i
struct fq *fq = &local->fq;
struct ieee80211_vif *vif;
struct txq_info *txqi;
- struct ieee80211_sta *pubsta;
if (!local->ops->wake_tx_queue ||
sdata->vif.type == NL80211_IFTYPE_MONITOR)
return false;
- if (sta && sta->uploaded)
- pubsta = &sta->sta;
- else
- pubsta = NULL;
-
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
sdata = container_of(sdata->bss,
struct ieee80211_sub_if_data, u.ap);
vif = &sdata->vif;
- txqi = ieee80211_get_txq(local, vif, pubsta, skb);
+ txqi = ieee80211_get_txq(local, vif, sta, skb);
if (!txqi)
return false;
Patches currently in stable-queue which might be from michal.kazior(a)tieto.com are
queue-4.9/mac80211-prevent-skb-txq-mismatch.patch
This is a note to let you know that I've just added the patch titled
mac80211: don't try to sleep in rate_control_rate_init()
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:
mac80211-don-t-try-to-sleep-in-rate_control_rate_init.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Mon, 23 Jan 2017 09:29:09 +0100
Subject: mac80211: don't try to sleep in rate_control_rate_init()
From: Johannes Berg <johannes.berg(a)intel.com>
[ Upstream commit 115865fa0826ed18ca04717cf72d0fe874c0fe7f ]
In my previous patch, I missed that rate_control_rate_init() is
called from some places that cannot sleep, so it cannot call
ieee80211_recalc_min_chandef(). Remove that call for now to fix
the context bug, we'll have to find a different way to fix the
minimum channel width issue.
Fixes: 96aa2e7cf126 ("mac80211: calculate min channel width correctly")
Reported-by: Xiaolong Ye (via lkp-robot) <xiaolong.ye(a)intel.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/rate.c | 2 --
1 file changed, 2 deletions(-)
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -40,8 +40,6 @@ void rate_control_rate_init(struct sta_i
ieee80211_sta_set_rx_nss(sta);
- ieee80211_recalc_min_chandef(sta->sdata);
-
if (!ref)
return;
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.9/mac80211-calculate-min-channel-width-correctly.patch
queue-4.9/mac80211-prevent-skb-txq-mismatch.patch
queue-4.9/mac80211-don-t-try-to-sleep-in-rate_control_rate_init.patch
This is a note to let you know that I've just added the patch titled
mac80211: calculate min channel width correctly
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:
mac80211-calculate-min-channel-width-correctly.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Fri, 7 Oct 2016 12:23:49 +0200
Subject: mac80211: calculate min channel width correctly
From: Johannes Berg <johannes.berg(a)intel.com>
[ Upstream commit 96aa2e7cf126773b16c6c19b7474a8a38d3c707e ]
In the current minimum chandef code there's an issue in that the
recalculation can happen after rate control is initialized for a
station that has a wider bandwidth than the current chanctx, and
then rate control can immediately start using those higher rates
which could cause problems.
Observe that first of all that this problem is because we don't
take non-associated and non-uploaded stations into account. The
restriction to non-associated is quite pointless and is one of
the causes for the problem described above, since the rate init
will happen before the station is set to associated; no frames
could actually be sent until associated, but the rate table can
already contain higher rates and that might cause problems.
Also, rejecting non-uploaded stations is wrong, since the rate
control can select higher rates for those as well.
Secondly, it's then necessary to recalculate the minimal config
before initializing rate control, so that when rate control is
initialized, the higher rates are already available. This can be
done easily by adding the necessary function call in rate init.
Change-Id: Ib9bc02d34797078db55459d196993f39dcd43070
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/chan.c | 3 ---
net/mac80211/rate.c | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -231,9 +231,6 @@ ieee80211_get_max_required_bw(struct iee
!(sta->sdata->bss && sta->sdata->bss == sdata->bss))
continue;
- if (!sta->uploaded || !test_sta_flag(sta, WLAN_STA_ASSOC))
- continue;
-
max_bw = max(max_bw, ieee80211_get_sta_bw(&sta->sta));
}
rcu_read_unlock();
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -40,6 +40,8 @@ void rate_control_rate_init(struct sta_i
ieee80211_sta_set_rx_nss(sta);
+ ieee80211_recalc_min_chandef(sta->sdata);
+
if (!ref)
return;
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.9/mac80211-calculate-min-channel-width-correctly.patch
queue-4.9/mac80211-prevent-skb-txq-mismatch.patch
queue-4.9/mac80211-don-t-try-to-sleep-in-rate_control_rate_init.patch
This is a note to let you know that I've just added the patch titled
m68k: fix ColdFire node shift size calculation
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:
m68k-fix-coldfire-node-shift-size-calculation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Greg Ungerer <gerg(a)linux-m68k.org>
Date: Tue, 5 Sep 2017 22:57:06 +1000
Subject: m68k: fix ColdFire node shift size calculation
From: Greg Ungerer <gerg(a)linux-m68k.org>
[ Upstream commit f55ab8f27548ff3431a6567d400c6757c49fd520 ]
The m68k pg_data_table is a fix size array defined in arch/m68k/mm/init.c.
Index numbers within it are defined based on memory size. But for Coldfire
these don't take into account a non-zero physical RAM base address, and this
causes us to access past the end of this array at system start time.
Change the node shift calculation so that we keep the index inside its range.
Reported-by: Angelo Dureghello <angelo(a)sysam.it>
Tested-by: Angelo Dureghello <angelo(a)sysam.it>
Signed-off-by: Greg Ungerer <gerg(a)linux-m68k.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/m68k/mm/mcfmmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -169,7 +169,7 @@ void __init cf_bootmem_alloc(void)
max_pfn = max_low_pfn = PFN_DOWN(_ramend);
high_memory = (void *)_ramend;
- m68k_virt_to_node_shift = fls(_ramend - _rambase - 1) - 6;
+ m68k_virt_to_node_shift = fls(_ramend - 1) - 6;
module_fixup(NULL, __start_fixup, __stop_fixup);
/* setup bootmem data */
Patches currently in stable-queue which might be from gerg(a)linux-m68k.org are
queue-4.9/m68k-fix-coldfire-node-shift-size-calculation.patch
This is a note to let you know that I've just added the patch titled
libfs: Modify mount_pseudo_xattr to be clear it is not a userspace mount
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:
libfs-modify-mount_pseudo_xattr-to-be-clear-it-is-not-a-userspace-mount.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Wed, 4 Jan 2017 17:37:27 +1300
Subject: libfs: Modify mount_pseudo_xattr to be clear it is not a userspace mount
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
[ Upstream commit 75422726b0f717d67db3283c2eb5bc14fa2619c5 ]
Add MS_KERNMOUNT to the flags that are passed.
Use sget_userns and force &init_user_ns instead of calling sget so that
even if called from a weird context the internal filesystem will be
considered to be in the intial user namespace.
Luis Ressel reported that the the failure to pass MS_KERNMOUNT into
mount_pseudo broke his in development graphics driver that uses the
generic drm infrastructure. I am not certain the deriver was bug
free in it's usage of that infrastructure but since
mount_pseudo_xattr can never be triggered by userspace it is clearer
and less error prone, and less problematic for the code to be explicit.
Reported-by: Luis Ressel <aranea(a)aixah.de>
Tested-by: Luis Ressel <aranea(a)aixah.de>
Acked-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/libfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -245,7 +245,8 @@ struct dentry *mount_pseudo_xattr(struct
struct inode *root;
struct qstr d_name = QSTR_INIT(name, strlen(name));
- s = sget(fs_type, NULL, set_anon_super, MS_NOUSER, NULL);
+ s = sget_userns(fs_type, NULL, set_anon_super, MS_KERNMOUNT|MS_NOUSER,
+ &init_user_ns, NULL);
if (IS_ERR(s))
return ERR_CAST(s);
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.9/libfs-modify-mount_pseudo_xattr-to-be-clear-it-is-not-a-userspace-mount.patch
This is a note to let you know that I've just added the patch titled
libcxgb: fix error check for ip6_route_output()
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:
libcxgb-fix-error-check-for-ip6_route_output.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Varun Prakash <varun(a)chelsio.com>
Date: Tue, 3 Jan 2017 21:25:48 +0530
Subject: libcxgb: fix error check for ip6_route_output()
From: Varun Prakash <varun(a)chelsio.com>
[ Upstream commit a9a8cdb368d99bb655b5cdabea560446db0527cc ]
ip6_route_output() never returns NULL so
check dst->error instead of !dst.
Signed-off-by: Varun Prakash <varun(a)chelsio.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
--- a/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c
+++ b/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c
@@ -133,17 +133,15 @@ cxgb_find_route6(struct cxgb4_lld_info *
if (ipv6_addr_type(&fl6.daddr) & IPV6_ADDR_LINKLOCAL)
fl6.flowi6_oif = sin6_scope_id;
dst = ip6_route_output(&init_net, NULL, &fl6);
- if (!dst)
- goto out;
- if (!cxgb_our_interface(lldi, get_real_dev,
- ip6_dst_idev(dst)->dev) &&
- !(ip6_dst_idev(dst)->dev->flags & IFF_LOOPBACK)) {
+ if (dst->error ||
+ (!cxgb_our_interface(lldi, get_real_dev,
+ ip6_dst_idev(dst)->dev) &&
+ !(ip6_dst_idev(dst)->dev->flags & IFF_LOOPBACK))) {
dst_release(dst);
- dst = NULL;
+ return NULL;
}
}
-out:
return dst;
}
EXPORT_SYMBOL(cxgb_find_route6);
Patches currently in stable-queue which might be from varun(a)chelsio.com are
queue-4.9/libcxgb-fix-error-check-for-ip6_route_output.patch
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: Fix occasional warning from the timer work function
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:
kvm-arm-arm64-fix-occasional-warning-from-the-timer-work-function.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Christoffer Dall <christoffer.dall(a)linaro.org>
Date: Mon, 9 Jan 2017 12:18:56 +0100
Subject: KVM: arm/arm64: Fix occasional warning from the timer work function
From: Christoffer Dall <christoffer.dall(a)linaro.org>
[ Upstream commit 63e41226afc3f7a044b70325566fa86ac3142538 ]
When a VCPU blocks (WFI) and has programmed the vtimer, we program a
soft timer to expire in the future to wake up the vcpu thread when
appropriate. Because such as wake up involves a vcpu kick, and the
timer expire function can get called from interrupt context, and the
kick may sleep, we have to schedule the kick in the work function.
The work function currently has a warning that gets raised if it turns
out that the timer shouldn't fire when it's run, which was added because
the idea was that in that case the work should never have been cancelled.
However, it turns out that this whole thing is racy and we can get
spurious warnings. The problem is that we clear the armed flag in the
work function, which may run in parallel with the
kvm_timer_unschedule->timer_disarm() call. This results in a possible
situation where the timer_disarm() call does not call
cancel_work_sync(), which effectively synchronizes the completion of the
work function with running the VCPU. As a result, the VCPU thread
proceeds before the work function completees, causing changes to the
timer state such that kvm_timer_should_fire(vcpu) returns false in the
work function.
All we do in the work function is to kick the VCPU, and an occasional
rare extra kick never harmed anyone. Since the race above is extremely
rare, we don't bother checking if the race happens but simply remove the
check and the clearing of the armed flag from the work function.
Reported-by: Matthias Brugger <mbrugger(a)suse.com>
Reviewed-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
virt/kvm/arm/arch_timer.c | 3 ---
1 file changed, 3 deletions(-)
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -89,9 +89,6 @@ static void kvm_timer_inject_irq_work(st
struct kvm_vcpu *vcpu;
vcpu = container_of(work, struct kvm_vcpu, arch.timer_cpu.expired);
- vcpu->arch.timer_cpu.armed = false;
-
- WARN_ON(!kvm_timer_should_fire(vcpu));
/*
* If the vcpu is blocked we want to wake it up so that it will see
Patches currently in stable-queue which might be from christoffer.dall(a)linaro.org are
queue-4.9/kvm-arm-arm64-fix-occasional-warning-from-the-timer-work-function.patch
This is a note to let you know that I've just added the patch titled
kprobes/x86: Disable preemption in ftrace-based jprobes
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:
kprobes-x86-disable-preemption-in-ftrace-based-jprobes.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Tue, 19 Sep 2017 19:01:40 +0900
Subject: kprobes/x86: Disable preemption in ftrace-based jprobes
From: Masami Hiramatsu <mhiramat(a)kernel.org>
[ Upstream commit 5bb4fc2d8641219732eb2bb654206775a4219aca ]
Disable preemption in ftrace-based jprobe handlers as
described in Documentation/kprobes.txt:
"Probe handlers are run with preemption disabled."
This will fix jprobes behavior when CONFIG_PREEMPT=y.
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Alexei Starovoitov <ast(a)fb.com>
Cc: Alexei Starovoitov <ast(a)kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth(a)linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Paul E . McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/150581530024.32348.9863783558598926771.stgit@devbox
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/ftrace.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -26,7 +26,7 @@
#include "common.h"
static nokprobe_inline
-int __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
+void __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb, unsigned long orig_ip)
{
/*
@@ -41,20 +41,21 @@ int __skip_singlestep(struct kprobe *p,
__this_cpu_write(current_kprobe, NULL);
if (orig_ip)
regs->ip = orig_ip;
- return 1;
}
int skip_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
- if (kprobe_ftrace(p))
- return __skip_singlestep(p, regs, kcb, 0);
- else
- return 0;
+ if (kprobe_ftrace(p)) {
+ __skip_singlestep(p, regs, kcb, 0);
+ preempt_enable_no_resched();
+ return 1;
+ }
+ return 0;
}
NOKPROBE_SYMBOL(skip_singlestep);
-/* Ftrace callback handler for kprobes */
+/* Ftrace callback handler for kprobes -- called under preepmt disabed */
void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *ops, struct pt_regs *regs)
{
@@ -77,13 +78,17 @@ void kprobe_ftrace_handler(unsigned long
/* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
regs->ip = ip + sizeof(kprobe_opcode_t);
+ /* To emulate trap based kprobes, preempt_disable here */
+ preempt_disable();
__this_cpu_write(current_kprobe, p);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
- if (!p->pre_handler || !p->pre_handler(p, regs))
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
__skip_singlestep(p, regs, kcb, orig_ip);
+ preempt_enable_no_resched();
+ }
/*
* If pre_handler returns !0, it sets regs->ip and
- * resets current kprobe.
+ * resets current kprobe, and keep preempt count +1.
*/
}
end:
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.9/kprobes-use-synchronize_rcu_tasks-for-optprobe-with-config_preempt-y.patch
queue-4.9/kprobes-x86-disable-preemption-in-ftrace-based-jprobes.patch
This is a note to let you know that I've just added the patch titled
kprobes: Use synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT=y
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:
kprobes-use-synchronize_rcu_tasks-for-optprobe-with-config_preempt-y.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Fri, 20 Oct 2017 08:43:39 +0900
Subject: kprobes: Use synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT=y
From: Masami Hiramatsu <mhiramat(a)kernel.org>
[ Upstream commit a30b85df7d599f626973e9cd3056fe755bd778e0 ]
We want to wait for all potentially preempted kprobes trampoline
execution to have completed. This guarantees that any freed
trampoline memory is not in use by any task in the system anymore.
synchronize_rcu_tasks() gives such a guarantee, so use it.
Also, this guarantees to wait for all potentially preempted tasks
on the instructions which will be replaced with a jump.
Since this becomes a problem only when CONFIG_PREEMPT=y, enable
CONFIG_TASKS_RCU=y for synchronize_rcu_tasks() in that case.
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Acked-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth(a)linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Naveen N . Rao <naveen.n.rao(a)linux.vnet.ibm.com>
Cc: Paul E . McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/150845661962.5443.17724352636247312231.stgit@devbox
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/Kconfig | 2 +-
kernel/kprobes.c | 14 ++++++++------
2 files changed, 9 insertions(+), 7 deletions(-)
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -83,7 +83,7 @@ config STATIC_KEYS_SELFTEST
config OPTPROBES
def_bool y
depends on KPROBES && HAVE_OPTPROBES
- depends on !PREEMPT
+ select TASKS_RCU if PREEMPT
config KPROBES_ON_FTRACE
def_bool y
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -540,13 +540,15 @@ static void kprobe_optimizer(struct work
do_unoptimize_kprobes();
/*
- * Step 2: Wait for quiesence period to ensure all running interrupts
- * are done. Because optprobe may modify multiple instructions
- * there is a chance that Nth instruction is interrupted. In that
- * case, running interrupt can return to 2nd-Nth byte of jump
- * instruction. This wait is for avoiding it.
+ * Step 2: Wait for quiesence period to ensure all potentially
+ * preempted tasks to have normally scheduled. Because optprobe
+ * may modify multiple instructions, there is a chance that Nth
+ * instruction is preempted. In that case, such tasks can return
+ * to 2nd-Nth byte of jump instruction. This wait is for avoiding it.
+ * Note that on non-preemptive kernel, this is transparently converted
+ * to synchronoze_sched() to wait for all interrupts to have completed.
*/
- synchronize_sched();
+ synchronize_rcu_tasks();
/* Step 3: Optimize kprobes after quiesence period */
do_optimize_kprobes();
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.9/kprobes-use-synchronize_rcu_tasks-for-optprobe-with-config_preempt-y.patch
queue-4.9/kprobes-x86-disable-preemption-in-ftrace-based-jprobes.patch
This is a note to let you know that I've just added the patch titled
ima: fix hash algorithm initialization
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:
ima-fix-hash-algorithm-initialization.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Boshi Wang <wangboshi(a)huawei.com>
Date: Fri, 20 Oct 2017 16:01:03 +0800
Subject: ima: fix hash algorithm initialization
From: Boshi Wang <wangboshi(a)huawei.com>
[ Upstream commit ebe7c0a7be92bbd34c6ff5b55810546a0ee05bee ]
The hash_setup function always sets the hash_setup_done flag, even
when the hash algorithm is invalid. This prevents the default hash
algorithm defined as CONFIG_IMA_DEFAULT_HASH from being used.
This patch sets hash_setup_done flag only for valid hash algorithms.
Fixes: e7a2ad7eb6f4 "ima: enable support for larger default filedata hash algorithms"
Signed-off-by: Boshi Wang <wangboshi(a)huawei.com>
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_main.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -51,6 +51,8 @@ static int __init hash_setup(char *str)
ima_hash_algo = HASH_ALGO_SHA1;
else if (strncmp(str, "md5", 3) == 0)
ima_hash_algo = HASH_ALGO_MD5;
+ else
+ return 1;
goto out;
}
@@ -60,6 +62,8 @@ static int __init hash_setup(char *str)
break;
}
}
+ if (i == HASH_ALGO__LAST)
+ return 1;
out:
hash_setup_done = 1;
return 1;
Patches currently in stable-queue which might be from wangboshi(a)huawei.com are
queue-4.9/ima-fix-hash-algorithm-initialization.patch
This is a note to let you know that I've just added the patch titled
iio: adc: ti-ads1015: add 10% to conversion wait time
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iio-adc-ti-ads1015-add-10-to-conversion-wait-time.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ladislav Michl <ladis(a)linux-mips.org>
Date: Fri, 25 Aug 2017 07:39:16 +0200
Subject: iio: adc: ti-ads1015: add 10% to conversion wait time
From: Ladislav Michl <ladis(a)linux-mips.org>
[ Upstream commit fe895ac88b9fbdf2026f0bfd56c82747bb9d7c48 ]
As user's guide "ADS1015EVM, ADS1115EVM, ADS1015EVM-PDK, ADS1115EVM-PDK
User Guide (Rev. B)" (http://www.ti.com/lit/ug/sbau157b/sbau157b.pdf)
states at page 16:
"Note that both the ADS1115 and ADS1015 have internal clocks with a ±10%
accuracy. If performing FFT tests, frequencies may appear to be incorrect
as a result of this tolerance range.", add those 10% to converion wait
time.
Cc: Daniel Baluta <daniel.baluta(a)gmail.com>
Cc: Jonathan Cameron <jic23(a)kernel.org>
Signed-off-by: Ladislav Michl <ladis(a)linux-mips.org>
Reviewed-by: Akinobu Mita <akinobu.mita(a)gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/adc/ti-ads1015.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/iio/adc/ti-ads1015.c
+++ b/drivers/iio/adc/ti-ads1015.c
@@ -269,6 +269,7 @@ int ads1015_get_adc_result(struct ads101
conv_time = DIV_ROUND_UP(USEC_PER_SEC, data->data_rate[dr_old]);
conv_time += DIV_ROUND_UP(USEC_PER_SEC, data->data_rate[dr]);
+ conv_time += conv_time / 10; /* 10% internal clock inaccuracy */
usleep_range(conv_time, conv_time + 1);
data->conv_invalid = false;
}
Patches currently in stable-queue which might be from ladis(a)linux-mips.org are
queue-4.9/iio-adc-ti-ads1015-add-10-to-conversion-wait-time.patch
This is a note to let you know that I've just added the patch titled
i2c: i2c-cadence: Initialize configuration before probing devices
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:
i2c-i2c-cadence-initialize-configuration-before-probing-devices.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Mike Looijmans <mike.looijmans(a)topic.nl>
Date: Mon, 16 Jan 2017 15:49:38 +0100
Subject: i2c: i2c-cadence: Initialize configuration before probing devices
From: Mike Looijmans <mike.looijmans(a)topic.nl>
[ Upstream commit 0e1929dedea36781e25902118c93edd8d8f09af1 ]
The cadence I2C driver calls cdns_i2c_writereg(..) to setup a workaround
in the controller, but did so after calling i2c_add_adapter() which starts
probing devices on the bus. Change the order so that the configuration is
completely finished before using the adapter.
Signed-off-by: Mike Looijmans <mike.looijmans(a)topic.nl>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/busses/i2c-cadence.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -962,10 +962,6 @@ static int cdns_i2c_probe(struct platfor
goto err_clk_dis;
}
- ret = i2c_add_adapter(&id->adap);
- if (ret < 0)
- goto err_clk_dis;
-
/*
* Cadence I2C controller has a bug wherein it generates
* invalid read transaction after HW timeout in master receiver mode.
@@ -975,6 +971,10 @@ static int cdns_i2c_probe(struct platfor
*/
cdns_i2c_writereg(CDNS_I2C_TIMEOUT_MAX, CDNS_I2C_TIME_OUT_OFFSET);
+ ret = i2c_add_adapter(&id->adap);
+ if (ret < 0)
+ goto err_clk_dis;
+
dev_info(&pdev->dev, "%u kHz mmio %08lx irq %d\n",
id->i2c_clk / 1000, (unsigned long)r_mem->start, id->irq);
Patches currently in stable-queue which might be from mike.looijmans(a)topic.nl are
queue-4.9/i2c-i2c-cadence-initialize-configuration-before-probing-devices.patch
This is a note to let you know that I've just added the patch titled
gtp: fix cross netns recv on gtp socket
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:
gtp-fix-cross-netns-recv-on-gtp-socket.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Andreas Schultz <aschultz(a)tpip.net>
Date: Fri, 27 Jan 2017 10:40:58 +0100
Subject: gtp: fix cross netns recv on gtp socket
From: Andreas Schultz <aschultz(a)tpip.net>
[ Upstream commit 3ab1b469e847ba425af3c5ad5068cc94b55b38d0 ]
The use of the passed through netlink src_net to check for a
cross netns operation was wrong. Using the GTP socket and the
GTP netdevice is always correct (even if the netdev has been
moved to new netns after link creation).
Remove the now obsolete net field from gtp_dev.
Signed-off-by: Andreas Schultz <aschultz(a)tpip.net>
Acked-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/gtp.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -69,7 +69,6 @@ struct gtp_dev {
struct socket *sock0;
struct socket *sock1u;
- struct net *net;
struct net_device *dev;
unsigned int hash_size;
@@ -316,7 +315,7 @@ static int gtp_encap_recv(struct sock *s
netdev_dbg(gtp->dev, "encap_recv sk=%p\n", sk);
- xnet = !net_eq(gtp->net, dev_net(gtp->dev));
+ xnet = !net_eq(sock_net(sk), dev_net(gtp->dev));
switch (udp_sk(sk)->encap_type) {
case UDP_ENCAP_GTP0:
@@ -658,7 +657,7 @@ static void gtp_link_setup(struct net_de
static int gtp_hashtable_new(struct gtp_dev *gtp, int hsize);
static void gtp_hashtable_free(struct gtp_dev *gtp);
static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp,
- int fd_gtp0, int fd_gtp1, struct net *src_net);
+ int fd_gtp0, int fd_gtp1);
static int gtp_newlink(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
@@ -675,7 +674,7 @@ static int gtp_newlink(struct net *src_n
fd0 = nla_get_u32(data[IFLA_GTP_FD0]);
fd1 = nla_get_u32(data[IFLA_GTP_FD1]);
- err = gtp_encap_enable(dev, gtp, fd0, fd1, src_net);
+ err = gtp_encap_enable(dev, gtp, fd0, fd1);
if (err < 0)
goto out_err;
@@ -821,7 +820,7 @@ static void gtp_hashtable_free(struct gt
}
static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp,
- int fd_gtp0, int fd_gtp1, struct net *src_net)
+ int fd_gtp0, int fd_gtp1)
{
struct udp_tunnel_sock_cfg tuncfg = {NULL};
struct socket *sock0, *sock1u;
@@ -858,7 +857,6 @@ static int gtp_encap_enable(struct net_d
gtp->sock0 = sock0;
gtp->sock1u = sock1u;
- gtp->net = src_net;
tuncfg.sk_user_data = gtp;
tuncfg.encap_rcv = gtp_encap_recv;
Patches currently in stable-queue which might be from aschultz(a)tpip.net are
queue-4.9/gtp-clear-df-bit-on-gtp-packet-tx.patch
queue-4.9/gtp-fix-cross-netns-recv-on-gtp-socket.patch
This is a note to let you know that I've just added the patch titled
gtp: clear DF bit on GTP packet tx
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:
gtp-clear-df-bit-on-gtp-packet-tx.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Andreas Schultz <aschultz(a)tpip.net>
Date: Fri, 27 Jan 2017 10:40:57 +0100
Subject: gtp: clear DF bit on GTP packet tx
From: Andreas Schultz <aschultz(a)tpip.net>
[ Upstream commit c6ce1d08eede4c2968ed08aafa3165e8e183c5a1 ]
3GPP TS 29.281 and 3GPP TS 29.060 imply that GTP-U packets should be
sent with the DF bit cleared. For example 3GPP TS 29.060, Release 8,
Section 13.2.2:
> Backbone router: Any router in the backbone may fragment the GTP
> packet if needed, according to IPv4.
Signed-off-by: Andreas Schultz <aschultz(a)tpip.net>
Acked-by: Harald Welte <laforge(a)netfilter.org>
Acked-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/gtp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -612,7 +612,7 @@ static netdev_tx_t gtp_dev_xmit(struct s
pktinfo.fl4.saddr, pktinfo.fl4.daddr,
pktinfo.iph->tos,
ip4_dst_hoplimit(&pktinfo.rt->dst),
- htons(IP_DF),
+ 0,
pktinfo.gtph_port, pktinfo.gtph_port,
true, false);
break;
Patches currently in stable-queue which might be from aschultz(a)tpip.net are
queue-4.9/gtp-clear-df-bit-on-gtp-packet-tx.patch
queue-4.9/gtp-fix-cross-netns-recv-on-gtp-socket.patch
This is a note to let you know that I've just added the patch titled
EDAC, sb_edac: Fix missing break in switch
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:
edac-sb_edac-fix-missing-break-in-switch.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Mon, 16 Oct 2017 12:40:29 -0500
Subject: EDAC, sb_edac: Fix missing break in switch
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit a8e9b186f153a44690ad0363a56716e7077ad28c ]
Add missing break statement in order to prevent the code from falling
through.
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Cc: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/20171016174029.GA19757@embeddedor.com
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/sb_edac.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -2510,6 +2510,7 @@ static int ibridge_mci_bind_devs(struct
break;
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA:
pvt->pci_ta = pdev;
+ break;
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_RAS:
pvt->pci_ras = pdev;
break;
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.9/edac-sb_edac-fix-missing-break-in-switch.patch
This is a note to let you know that I've just added the patch titled
drm/exynos/decon5433: update shadow registers iff there are active windows
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:
drm-exynos-decon5433-update-shadow-registers-iff-there-are-active-windows.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Andrzej Hajda <a.hajda(a)samsung.com>
Date: Mon, 9 Jan 2017 15:33:02 +0100
Subject: drm/exynos/decon5433: update shadow registers iff there are active windows
From: Andrzej Hajda <a.hajda(a)samsung.com>
[ Upstream commit f65a7c9cb3770ed4d3e7c57c66d7032689081b5e ]
Improper usage of DECON_UPDATE register leads to subtle errors.
If it set in decon_commit when there are no active windows it results
in slow registry updates - all subsequent shadow registry updates takes more
than full vblank. On the other side if it is not set when there are
active windows it results in garbage on the screen after suspend/resume of
FB console.
The patch hopefully fixes it.
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Signed-off-by: Inki Dae <inki.dae(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -188,8 +188,6 @@ static void decon_commit(struct exynos_d
/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
-
- decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
}
static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
@@ -340,8 +338,9 @@ static void decon_atomic_flush(struct ex
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);
- /* standalone update */
- decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
+ /* update iff there are active windows */
+ if (crtc->base.state->plane_mask)
+ decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
if (ctx->out_type & IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, &ctx->flags);
Patches currently in stable-queue which might be from a.hajda(a)samsung.com are
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-also-if-planes-are-disabled.patch
queue-4.9/drm-exynos-decon5433-update-shadow-registers-iff-there-are-active-windows.patch
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
This is a note to let you know that I've just added the patch titled
drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
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:
drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Andrzej Hajda <a.hajda(a)samsung.com>
Date: Tue, 17 Jan 2017 15:15:20 +0100
Subject: drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
From: Andrzej Hajda <a.hajda(a)samsung.com>
[ Upstream commit 11d8bcef7a0399e1d2519f207fd575fc404306b4 ]
DECON_TV requires STANDALONE_UPDATE after output enabling, otherwise it does
not start. This change is neutral for DECON.
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Signed-off-by: Inki Dae <inki.dae(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -189,6 +189,8 @@ static void decon_commit(struct exynos_d
/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
+
+ decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
}
static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
Patches currently in stable-queue which might be from a.hajda(a)samsung.com are
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-also-if-planes-are-disabled.patch
queue-4.9/drm-exynos-decon5433-update-shadow-registers-iff-there-are-active-windows.patch
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
This is a note to let you know that I've just added the patch titled
drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-exynos-decon5433-set-standalone_update_f-also-if-planes-are-disabled.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Andrzej Hajda <a.hajda(a)samsung.com>
Date: Fri, 13 Jan 2017 10:20:58 +0100
Subject: drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
From: Andrzej Hajda <a.hajda(a)samsung.com>
[ Upstream commit 821b40b79db7dedbfe15ab330dfd181e661a533f ]
STANDALONE_UPDATE_F should be set if something changed in plane configurations,
including plane disable.
The patch fixes page-faults bugs, caused by decon still using framebuffers
of disabled planes.
v2: fixed clear-bit code (Thx Marek)
v3: use test_and_clear_bit (Thx Joonyoung)
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Tested-by: Joonyoung Shim <jy0922.shim(a)samsung.com>
Signed-off-by: Inki Dae <inki.dae(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -46,7 +46,8 @@ enum decon_flag_bits {
BIT_CLKS_ENABLED,
BIT_IRQS_ENABLED,
BIT_WIN_UPDATED,
- BIT_SUSPENDED
+ BIT_SUSPENDED,
+ BIT_REQUEST_UPDATE
};
struct decon_context {
@@ -313,6 +314,7 @@ static void decon_update_plane(struct ex
/* window enable */
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -325,6 +327,7 @@ static void decon_disable_plane(struct e
return;
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
@@ -338,8 +341,7 @@ static void decon_atomic_flush(struct ex
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);
- /* update iff there are active windows */
- if (crtc->base.state->plane_mask)
+ if (test_and_clear_bit(BIT_REQUEST_UPDATE, &ctx->flags))
decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
if (ctx->out_type & IFTYPE_I80)
Patches currently in stable-queue which might be from a.hajda(a)samsung.com are
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-also-if-planes-are-disabled.patch
queue-4.9/drm-exynos-decon5433-update-shadow-registers-iff-there-are-active-windows.patch
queue-4.9/drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: fix unload driver issue for virtual display
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:
drm-amdgpu-fix-unload-driver-issue-for-virtual-display.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Xiangliang Yu <Xiangliang.Yu(a)amd.com>
Date: Thu, 19 Jan 2017 09:57:41 +0800
Subject: drm/amdgpu: fix unload driver issue for virtual display
From: Xiangliang Yu <Xiangliang.Yu(a)amd.com>
[ Upstream commit 3a1d19a29670aa7eb58576a31883d0aa9fb77549 ]
Virtual display doesn't allocate amdgpu_encoder when initializing,
so will get invaild pointer if try to free amdgpu_encoder when
unloading driver.
Signed-off-by: Xiangliang Yu <Xiangliang.Yu(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Acked-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -565,11 +565,8 @@ static const struct drm_encoder_helper_f
static void dce_virtual_encoder_destroy(struct drm_encoder *encoder)
{
- struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
-
- kfree(amdgpu_encoder->enc_priv);
drm_encoder_cleanup(encoder);
- kfree(amdgpu_encoder);
+ kfree(encoder);
}
static const struct drm_encoder_funcs dce_virtual_encoder_funcs = {
Patches currently in stable-queue which might be from Xiangliang.Yu(a)amd.com are
queue-4.9/drm-amdgpu-fix-unload-driver-issue-for-virtual-display.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: fix bug set incorrect value to vce register
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-fix-bug-set-incorrect-value-to-vce-register.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Rex Zhu <Rex.Zhu(a)amd.com>
Date: Tue, 10 Jan 2017 20:00:40 +0800
Subject: drm/amdgpu: fix bug set incorrect value to vce register
From: Rex Zhu <Rex.Zhu(a)amd.com>
[ Upstream commit e05208ded1905e500cd5b369d624b071951c68b9 ]
Set the proper bits for clockgating setup.
Signed-off-by: Rex Zhu <Rex.Zhu(a)amd.com>
Acked-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -182,7 +182,7 @@ static void vce_v3_0_set_vce_sw_clock_ga
WREG32(mmVCE_UENC_CLOCK_GATING_2, data);
data = RREG32(mmVCE_UENC_REG_CLOCK_GATING);
- data &= ~0xffc00000;
+ data &= ~0x3ff;
WREG32(mmVCE_UENC_REG_CLOCK_GATING, data);
data = RREG32(mmVCE_UENC_DMA_DCLK_CTRL);
Patches currently in stable-queue which might be from Rex.Zhu(a)amd.com are
queue-4.9/drm-amdgpu-fix-bug-set-incorrect-value-to-vce-register.patch
This is a note to let you know that I've just added the patch titled
dmaengine: stm32-dma: Set correct args number for DMA request from DT
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-stm32-dma-set-correct-args-number-for-dma-request-from-dt.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
Date: Tue, 13 Dec 2016 14:40:43 +0100
Subject: dmaengine: stm32-dma: Set correct args number for DMA request from DT
From: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
[ Upstream commit 7e96304d99477de1f70db42035071e56439da817 ]
This patch sets the right number of arguments to be used for DMA clients
which request channels from DT.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre(a)st.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/stm32-dma.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -976,21 +976,18 @@ static struct dma_chan *stm32_dma_of_xla
struct stm32_dma_chan *chan;
struct dma_chan *c;
- if (dma_spec->args_count < 3)
+ if (dma_spec->args_count < 4)
return NULL;
cfg.channel_id = dma_spec->args[0];
cfg.request_line = dma_spec->args[1];
cfg.stream_config = dma_spec->args[2];
- cfg.threshold = 0;
+ cfg.threshold = dma_spec->args[3];
if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) || (cfg.request_line >=
STM32_DMA_MAX_REQUEST_ID))
return NULL;
- if (dma_spec->args_count > 3)
- cfg.threshold = dma_spec->args[3];
-
chan = &dmadev->chan[cfg.channel_id];
c = dma_get_slave_channel(&chan->vchan.chan);
Patches currently in stable-queue which might be from cedric.madianga(a)gmail.com are
queue-4.9/dmaengine-stm32-dma-fix-null-pointer-dereference-in-stm32_dma_tx_status.patch
queue-4.9/dmaengine-stm32-dma-set-correct-args-number-for-dma-request-from-dt.patch
This is a note to let you know that I've just added the patch titled
dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-stm32-dma-fix-null-pointer-dereference-in-stm32_dma_tx_status.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
Date: Tue, 13 Dec 2016 14:40:46 +0100
Subject: dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status
From: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
[ Upstream commit 57b5a32135c813f2ab669039fb4ec16b30cb3305 ]
chan->desc is always set to NULL when a DMA transfer is complete.
As a DMA transfer could be complete during the call of stm32_dma_tx_status,
we need to be sure that chan->desc is not NULL before using this variable
to avoid a null pointer deference issue.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga(a)gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre(a)st.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/stm32-dma.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -884,7 +884,7 @@ static enum dma_status stm32_dma_tx_stat
struct virt_dma_desc *vdesc;
enum dma_status status;
unsigned long flags;
- u32 residue;
+ u32 residue = 0;
status = dma_cookie_status(c, cookie, state);
if ((status == DMA_COMPLETE) || (!state))
@@ -892,16 +892,12 @@ static enum dma_status stm32_dma_tx_stat
spin_lock_irqsave(&chan->vchan.lock, flags);
vdesc = vchan_find_desc(&chan->vchan, cookie);
- if (cookie == chan->desc->vdesc.tx.cookie) {
+ if (chan->desc && cookie == chan->desc->vdesc.tx.cookie)
residue = stm32_dma_desc_residue(chan, chan->desc,
chan->next_sg);
- } else if (vdesc) {
+ else if (vdesc)
residue = stm32_dma_desc_residue(chan,
to_stm32_dma_desc(vdesc), 0);
- } else {
- residue = 0;
- }
-
dma_set_residue(state, residue);
spin_unlock_irqrestore(&chan->vchan.lock, flags);
Patches currently in stable-queue which might be from cedric.madianga(a)gmail.com are
queue-4.9/dmaengine-stm32-dma-fix-null-pointer-dereference-in-stm32_dma_tx_status.patch
queue-4.9/dmaengine-stm32-dma-set-correct-args-number-for-dma-request-from-dt.patch
This is a note to let you know that I've just added the patch titled
dmaengine: pl330: fix double lock
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-pl330-fix-double-lock.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Iago Abal <mail(a)iagoabal.eu>
Date: Wed, 11 Jan 2017 14:00:21 +0100
Subject: dmaengine: pl330: fix double lock
From: Iago Abal <mail(a)iagoabal.eu>
[ Upstream commit 91539eb1fda2d530d3b268eef542c5414e54bf1a ]
The static bug finder EBA (http://www.iagoabal.eu/eba/) reported the
following double-lock bug:
Double lock:
1. spin_lock_irqsave(pch->lock, flags) at pl330_free_chan_resources:2236;
2. call to function `pl330_release_channel' immediately after;
3. call to function `dma_pl330_rqcb' in line 1753;
4. spin_lock_irqsave(pch->lock, flags) at dma_pl330_rqcb:1505.
I have fixed it as suggested by Marek Szyprowski.
First, I have replaced `pch->lock' with `pl330->lock' in functions
`pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids
the double-lock by acquiring a different lock than `dma_pl330_rqcb'.
NOTE that, as a result, `pl330_free_chan_resources' executes
`list_splice_tail_init' on `pch->work_list' under lock `pl330->lock',
whereas in the rest of the code `pch->work_list' is protected by
`pch->lock'. I don't know if this may cause race conditions. Similarly
`pch->cyclic' is written by `pl330_alloc_chan_resources' under
`pl330->lock' but read by `pl330_tx_submit' under `pch->lock'.
Second, I have removed locking from `pl330_request_channel' and
`pl330_release_channel' functions. Function `pl330_request_channel' is
only called from `pl330_alloc_chan_resources', so the lock is already
held. Function `pl330_release_channel' is called from
`pl330_free_chan_resources', which already holds the lock, and from
`pl330_del'. Function `pl330_del' is called in an error path of
`pl330_probe' and at the end of `pl330_remove', but I assume that there
cannot be concurrent accesses to the protected data at those points.
Signed-off-by: Iago Abal <mail(a)iagoabal.eu>
Reviewed-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/pl330.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1694,7 +1694,6 @@ static bool _chan_ns(const struct pl330_
static struct pl330_thread *pl330_request_channel(struct pl330_dmac *pl330)
{
struct pl330_thread *thrd = NULL;
- unsigned long flags;
int chans, i;
if (pl330->state == DYING)
@@ -1702,8 +1701,6 @@ static struct pl330_thread *pl330_reques
chans = pl330->pcfg.num_chan;
- spin_lock_irqsave(&pl330->lock, flags);
-
for (i = 0; i < chans; i++) {
thrd = &pl330->channels[i];
if ((thrd->free) && (!_manager_ns(thrd) ||
@@ -1721,8 +1718,6 @@ static struct pl330_thread *pl330_reques
thrd = NULL;
}
- spin_unlock_irqrestore(&pl330->lock, flags);
-
return thrd;
}
@@ -1740,7 +1735,6 @@ static inline void _free_event(struct pl
static void pl330_release_channel(struct pl330_thread *thrd)
{
struct pl330_dmac *pl330;
- unsigned long flags;
if (!thrd || thrd->free)
return;
@@ -1752,10 +1746,8 @@ static void pl330_release_channel(struct
pl330 = thrd->dmac;
- spin_lock_irqsave(&pl330->lock, flags);
_free_event(thrd, thrd->ev);
thrd->free = true;
- spin_unlock_irqrestore(&pl330->lock, flags);
}
/* Initialize the structure for PL330 configuration, that can be used
@@ -2120,20 +2112,20 @@ static int pl330_alloc_chan_resources(st
struct pl330_dmac *pl330 = pch->dmac;
unsigned long flags;
- spin_lock_irqsave(&pch->lock, flags);
+ spin_lock_irqsave(&pl330->lock, flags);
dma_cookie_init(chan);
pch->cyclic = false;
pch->thread = pl330_request_channel(pl330);
if (!pch->thread) {
- spin_unlock_irqrestore(&pch->lock, flags);
+ spin_unlock_irqrestore(&pl330->lock, flags);
return -ENOMEM;
}
tasklet_init(&pch->task, pl330_tasklet, (unsigned long) pch);
- spin_unlock_irqrestore(&pch->lock, flags);
+ spin_unlock_irqrestore(&pl330->lock, flags);
return 1;
}
@@ -2236,12 +2228,13 @@ static int pl330_pause(struct dma_chan *
static void pl330_free_chan_resources(struct dma_chan *chan)
{
struct dma_pl330_chan *pch = to_pchan(chan);
+ struct pl330_dmac *pl330 = pch->dmac;
unsigned long flags;
tasklet_kill(&pch->task);
pm_runtime_get_sync(pch->dmac->ddma.dev);
- spin_lock_irqsave(&pch->lock, flags);
+ spin_lock_irqsave(&pl330->lock, flags);
pl330_release_channel(pch->thread);
pch->thread = NULL;
@@ -2249,7 +2242,7 @@ static void pl330_free_chan_resources(st
if (pch->cyclic)
list_splice_tail_init(&pch->work_list, &pch->dmac->desc_pool);
- spin_unlock_irqrestore(&pch->lock, flags);
+ spin_unlock_irqrestore(&pl330->lock, flags);
pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
}
Patches currently in stable-queue which might be from mail(a)iagoabal.eu are
queue-4.9/dmaengine-pl330-fix-double-lock.patch
This is a note to let you know that I've just added the patch titled
dax: Avoid page invalidation races and unnecessary radix tree traversals
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:
dax-avoid-page-invalidation-races-and-unnecessary-radix-tree-traversals.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Wed, 10 Aug 2016 17:10:28 +0200
Subject: dax: Avoid page invalidation races and unnecessary radix tree traversals
From: Jan Kara <jack(a)suse.cz>
[ Upstream commit e3fce68cdbed297d927e993b3ea7b8b1cee545da ]
Currently dax_iomap_rw() takes care of invalidating page tables and
evicting hole pages from the radix tree when write(2) to the file
happens. This invalidation is only necessary when there is some block
allocation resulting from write(2). Furthermore in current place the
invalidation is racy wrt page fault instantiating a hole page just after
we have invalidated it.
So perform the page invalidation inside dax_iomap_actor() where we can
do it only when really necessary and after blocks have been allocated so
nobody will be instantiating new hole pages anymore.
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/dax.c | 28 +++++++++++-----------------
1 file changed, 11 insertions(+), 17 deletions(-)
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1265,6 +1265,17 @@ iomap_dax_actor(struct inode *inode, lof
if (WARN_ON_ONCE(iomap->type != IOMAP_MAPPED))
return -EIO;
+ /*
+ * Write can allocate block for an area which has a hole page mapped
+ * into page tables. We have to tear down these mappings so that data
+ * written by write(2) is visible in mmap.
+ */
+ if ((iomap->flags & IOMAP_F_NEW) && inode->i_mapping->nrpages) {
+ invalidate_inode_pages2_range(inode->i_mapping,
+ pos >> PAGE_SHIFT,
+ (end - 1) >> PAGE_SHIFT);
+ }
+
while (pos < end) {
unsigned offset = pos & (PAGE_SIZE - 1);
struct blk_dax_ctl dax = { 0 };
@@ -1329,23 +1340,6 @@ iomap_dax_rw(struct kiocb *iocb, struct
if (iov_iter_rw(iter) == WRITE)
flags |= IOMAP_WRITE;
- /*
- * Yes, even DAX files can have page cache attached to them: A zeroed
- * page is inserted into the pagecache when we have to serve a write
- * fault on a hole. It should never be dirtied and can simply be
- * dropped from the pagecache once we get real data for the page.
- *
- * XXX: This is racy against mmap, and there's nothing we can do about
- * it. We'll eventually need to shift this down even further so that
- * we can check if we allocated blocks over a hole first.
- */
- if (mapping->nrpages) {
- ret = invalidate_inode_pages2_range(mapping,
- pos >> PAGE_SHIFT,
- (pos + iov_iter_count(iter) - 1) >> PAGE_SHIFT);
- WARN_ON_ONCE(ret);
- }
-
while (iov_iter_count(iter)) {
ret = iomap_apply(inode, pos, iov_iter_count(iter), flags, ops,
iter, iomap_dax_actor);
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.9/mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
queue-4.9/dax-avoid-page-invalidation-races-and-unnecessary-radix-tree-traversals.patch
This is a note to let you know that I've just added the patch titled
[media] cec: initiator should be the same as the destination for, poll
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:
cec-initiator-should-be-the-same-as-the-destination-for-poll.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Sat, 11 Feb 2017 09:24:46 -0200
Subject: [media] cec: initiator should be the same as the destination for, poll
From: Hans Verkuil <hverkuil(a)xs4all.nl>
[ Upstream commit 42980da2eb7eb9695d8efc0c0ef145cbbb993b2c ]
Poll messages that are used to allocate a logical address should
use the same initiator as the destination. Instead, it expected that
the initiator was 0xf which is not according to the standard.
This also had consequences for the message checks in cec_transmit_msg_fh
that incorrectly rejected poll messages with the same initiator and
destination.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/media/cec/cec-adap.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -608,8 +608,7 @@ int cec_transmit_msg_fh(struct cec_adapt
}
memset(msg->msg + msg->len, 0, sizeof(msg->msg) - msg->len);
if (msg->len == 1) {
- if (cec_msg_initiator(msg) != 0xf ||
- cec_msg_destination(msg) == 0xf) {
+ if (cec_msg_destination(msg) == 0xf) {
dprintk(1, "cec_transmit_msg: invalid poll message\n");
return -EINVAL;
}
@@ -634,7 +633,7 @@ int cec_transmit_msg_fh(struct cec_adapt
dprintk(1, "cec_transmit_msg: destination is the adapter itself\n");
return -EINVAL;
}
- if (cec_msg_initiator(msg) != 0xf &&
+ if (msg->len > 1 && adap->is_configured &&
!cec_has_log_addr(adap, cec_msg_initiator(msg))) {
dprintk(1, "cec_transmit_msg: initiator has unknown logical address %d\n",
cec_msg_initiator(msg));
@@ -883,7 +882,7 @@ static int cec_config_log_addr(struct ce
/* Send poll message */
msg.len = 1;
- msg.msg[0] = 0xf0 | log_addr;
+ msg.msg[0] = (log_addr << 4) | log_addr;
err = cec_transmit_msg_fh(adap, &msg, NULL, true);
/*
Patches currently in stable-queue which might be from hverkuil(a)xs4all.nl are
queue-4.9/cec-initiator-should-be-the-same-as-the-destination-for-poll.patch
This is a note to let you know that I've just added the patch titled
be2net: fix initial MAC setting
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:
be2net-fix-initial-mac-setting.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ivan Vecera <cera(a)cera.cz>
Date: Tue, 31 Jan 2017 20:01:31 +0100
Subject: be2net: fix initial MAC setting
From: Ivan Vecera <cera(a)cera.cz>
[ Upstream commit 4993b39ab04b083ff6ee1147e7e7f120feb6bf7f ]
Recent commit 34393529163a ("be2net: fix MAC addr setting on privileged
BE3 VFs") allows privileged BE3 VFs to set its MAC address during
initialization. Although the initial MAC for such VFs is already
programmed by parent PF the subsequent setting performed by VF is OK,
but in certain cases (after fresh boot) this command in VF can fail.
The MAC should be initialized only when:
1) no MAC is programmed (always except BE3 VFs during first init)
2) programmed MAC is different from requested (e.g. MAC is set when
interface is down). In this case the initial MAC programmed by PF
needs to be deleted.
The adapter->dev_mac contains MAC address currently programmed in HW so
it should be zeroed when the MAC is deleted from HW and should not be
filled when MAC is set when interface is down in be_mac_addr_set() as
no programming is performed in this case.
Example of failure without the fix (immediately after fresh boot):
# ip link set eth0 up <- eth0 is BE3 PF
be2net 0000:01:00.0 eth0: Link is Up
# echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create 1 VF
...
be2net 0000:01:04.0: Emulex OneConnect(be3): VF port 0
# ip link set eth8 up <- eth8 is created privileged VF
be2net 0000:01:04.0: opcode 59-1 failed:status 1-76
RTNETLINK answers: Input/output error
# echo 0 > /sys/class/net/eth0/device/sriov_numvfs <- Delete VF
iommu: Removing device 0000:01:04.0 from group 33
...
# echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create it again
iommu: Removing device 0000:01:04.0 from group 33
...
# ip link set eth8 up
be2net 0000:01:04.0 eth8: Link is Up
Initialization is now OK.
v2 - Corrected the comment and condition check suggested by Suresh & Harsha
Fixes: 34393529163a ("be2net: fix MAC addr setting on privileged BE3 VFs")
Cc: Sathya Perla <sathya.perla(a)broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde(a)broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com>
Cc: Somnath Kotur <somnath.kotur(a)broadcom.com>
Signed-off-by: Ivan Vecera <cera(a)cera.cz>
Acked-by: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/emulex/benet/be_main.c | 33 +++++++++++++++++++++++-----
1 file changed, 28 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -362,8 +362,10 @@ static int be_mac_addr_set(struct net_de
status = -EPERM;
goto err;
}
-done:
+
+ /* Remember currently programmed MAC */
ether_addr_copy(adapter->dev_mac, addr->sa_data);
+done:
ether_addr_copy(netdev->dev_addr, addr->sa_data);
dev_info(dev, "MAC address changed to %pM\n", addr->sa_data);
return 0;
@@ -3635,8 +3637,10 @@ static void be_disable_if_filters(struct
{
/* Don't delete MAC on BE3 VFs without FILTMGMT privilege */
if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
- check_privilege(adapter, BE_PRIV_FILTMGMT))
+ check_privilege(adapter, BE_PRIV_FILTMGMT)) {
be_dev_mac_del(adapter, adapter->pmac_id[0]);
+ eth_zero_addr(adapter->dev_mac);
+ }
be_clear_uc_list(adapter);
be_clear_mc_list(adapter);
@@ -3790,12 +3794,27 @@ static int be_enable_if_filters(struct b
if (status)
return status;
- /* Don't add MAC on BE3 VFs without FILTMGMT privilege */
- if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
- check_privilege(adapter, BE_PRIV_FILTMGMT)) {
+ /* Normally this condition usually true as the ->dev_mac is zeroed.
+ * But on BE3 VFs the initial MAC is pre-programmed by PF and
+ * subsequent be_dev_mac_add() can fail (after fresh boot)
+ */
+ if (!ether_addr_equal(adapter->dev_mac, adapter->netdev->dev_addr)) {
+ int old_pmac_id = -1;
+
+ /* Remember old programmed MAC if any - can happen on BE3 VF */
+ if (!is_zero_ether_addr(adapter->dev_mac))
+ old_pmac_id = adapter->pmac_id[0];
+
status = be_dev_mac_add(adapter, adapter->netdev->dev_addr);
if (status)
return status;
+
+ /* Delete the old programmed MAC as we successfully programmed
+ * a new MAC
+ */
+ if (old_pmac_id >= 0 && old_pmac_id != adapter->pmac_id[0])
+ be_dev_mac_del(adapter, old_pmac_id);
+
ether_addr_copy(adapter->dev_mac, adapter->netdev->dev_addr);
}
@@ -4569,6 +4588,10 @@ static int be_mac_setup(struct be_adapte
memcpy(adapter->netdev->dev_addr, mac, ETH_ALEN);
memcpy(adapter->netdev->perm_addr, mac, ETH_ALEN);
+
+ /* Initial MAC for BE3 VFs is already programmed by PF */
+ if (BEx_chip(adapter) && be_virtfn(adapter))
+ memcpy(adapter->dev_mac, mac, ETH_ALEN);
}
return 0;
Patches currently in stable-queue which might be from cera(a)cera.cz are
queue-4.9/be2net-fix-accesses-to-unicast-list.patch
queue-4.9/be2net-fix-initial-mac-setting.patch
queue-4.9/be2net-fix-unicast-list-filling.patch
This is a note to let you know that I've just added the patch titled
be2net: fix unicast list filling
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:
be2net-fix-unicast-list-filling.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ivan Vecera <cera(a)cera.cz>
Date: Fri, 6 Jan 2017 21:59:30 +0100
Subject: be2net: fix unicast list filling
From: Ivan Vecera <cera(a)cera.cz>
[ Upstream commit 6052cd1af86f9833b6b0b60d5d4787c4a06d65ea ]
The adapter->pmac_id[0] item is used for primary MAC address but
this is not true for adapter->uc_list[0] as is assumed in
be_set_uc_list(). There are N UC addresses copied first from net_device
to adapter->uc_list[1..N] and then N UC addresses from
adapter->uc_list[0..N-1] are sent to HW. So the last UC address is never
stored into HW and address 00:00:00:00;00:00 (from uc_list[0]) is used
instead.
Cc: Sathya Perla <sathya.perla(a)broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde(a)broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com>
Cc: Somnath Kotur <somnath.kotur(a)broadcom.com>
Fixes: b717241 be2net: replace polling with sleeping in the FW completion path
Signed-off-by: Ivan Vecera <cera(a)cera.cz>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/emulex/benet/be_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1719,9 +1719,8 @@ static void be_set_uc_list(struct be_ada
}
if (adapter->update_uc_list) {
- i = 1; /* First slot is claimed by the Primary MAC */
-
/* cache the uc-list in adapter array */
+ i = 0;
netdev_for_each_uc_addr(ha, netdev) {
ether_addr_copy(adapter->uc_list[i].mac, ha->addr);
i++;
Patches currently in stable-queue which might be from cera(a)cera.cz are
queue-4.9/be2net-fix-accesses-to-unicast-list.patch
queue-4.9/be2net-fix-initial-mac-setting.patch
queue-4.9/be2net-fix-unicast-list-filling.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP2+: Fix WL1283 Bluetooth Baud Rate
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-omap2-fix-wl1283-bluetooth-baud-rate.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Adam Ford <aford173(a)gmail.com>
Date: Tue, 3 Jan 2017 11:37:48 -0600
Subject: ARM: OMAP2+: Fix WL1283 Bluetooth Baud Rate
From: Adam Ford <aford173(a)gmail.com>
[ Upstream commit a3ac350793d90d1da631c8beeee9352387974ed5 ]
Commit 485fa1261f78 ("ARM: OMAP2+: LogicPD Torpedo + Wireless: Add Bluetooth")
set the wrong baud rate for the UART. The Baud rate was 300,000 and it should
be 3,000,000 for WL1283.
Signed-off-by: Adam Ford <aford173(a)gmail.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap2/pdata-quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -147,7 +147,7 @@ static struct ti_st_plat_data wilink_pda
.nshutdown_gpio = 137,
.dev_name = "/dev/ttyO1",
.flow_cntrl = 1,
- .baud_rate = 300000,
+ .baud_rate = 3000000,
};
static struct platform_device wl18xx_device = {
Patches currently in stable-queue which might be from aford173(a)gmail.com are
queue-4.9/arm-omap2-fix-wl1283-bluetooth-baud-rate.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP1: DMA: Correct the number of logical channels
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-omap1-dma-correct-the-number-of-logical-channels.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Tue, 3 Jan 2017 13:22:34 +0200
Subject: ARM: OMAP1: DMA: Correct the number of logical channels
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit 657279778af54f35e54b07b6687918f254a2992c ]
OMAP1510, OMAP5910 and OMAP310 have only 9 logical channels.
OMAP1610, OMAP5912, OMAP1710, OMAP730, and OMAP850 have 16 logical channels
available.
The wired 17 for the lch_count must have been used to cover the 16 + 1
dedicated LCD channel, in reality we can only use 9 or 16 channels.
The d->chan_count is not used by the omap-dma stack, so we can skip the
setup. chan_count was configured to the number of logical channels and not
the actual number of physical channels anyways.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Acked-by: Aaro Koskinen <aaro.koskinen(a)iki.fi>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap1/dma.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -32,7 +32,6 @@
#include "soc.h"
#define OMAP1_DMA_BASE (0xfffed800)
-#define OMAP1_LOGICAL_DMA_CH_COUNT 17
static u32 enable_1510_mode;
@@ -348,8 +347,6 @@ static int __init omap1_system_dma_init(
goto exit_iounmap;
}
- d->lch_count = OMAP1_LOGICAL_DMA_CH_COUNT;
-
/* Valid attributes for omap1 plus processors */
if (cpu_is_omap15xx())
d->dev_caps = ENABLE_1510_MODE;
@@ -366,13 +363,14 @@ static int __init omap1_system_dma_init(
d->dev_caps |= CLEAR_CSR_ON_READ;
d->dev_caps |= IS_WORD_16;
- if (cpu_is_omap15xx())
- d->chan_count = 9;
- else if (cpu_is_omap16xx() || cpu_is_omap7xx()) {
- if (!(d->dev_caps & ENABLE_1510_MODE))
- d->chan_count = 16;
+ /* available logical channels */
+ if (cpu_is_omap15xx()) {
+ d->lch_count = 9;
+ } else {
+ if (d->dev_caps & ENABLE_1510_MODE)
+ d->lch_count = 9;
else
- d->chan_count = 9;
+ d->lch_count = 16;
}
p = dma_plat_info;
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.9/arm-omap1-dma-correct-the-number-of-logical-channels.patch
This is a note to let you know that I've just added the patch titled
be2net: fix accesses to unicast list
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:
be2net-fix-accesses-to-unicast-list.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Ivan Vecera <cera(a)cera.cz>
Date: Fri, 6 Jan 2017 20:30:02 +0100
Subject: be2net: fix accesses to unicast list
From: Ivan Vecera <cera(a)cera.cz>
[ Upstream commit 1d0f110a2c6c4bca3dbcc4b0e27f1e3dc2d44a2c ]
Commit 988d44b "be2net: Avoid redundant addition of mac address in HW"
introduced be_dev_mac_add & be_uc_mac_add helpers that incorrectly
access adapter->uc_list as an array of bytes instead of an array of
be_eth_addr. Consequently NIC is not filled with valid data so unicast
filtering is broken.
Cc: Sathya Perla <sathya.perla(a)broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde(a)broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com>
Cc: Somnath Kotur <somnath.kotur(a)broadcom.com>
Fixes: 988d44b be2net: Avoid redundant addition of mac address in HW
Signed-off-by: Ivan Vecera <cera(a)cera.cz>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/emulex/benet/be_main.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -275,8 +275,7 @@ static int be_dev_mac_add(struct be_adap
/* Check if mac has already been added as part of uc-list */
for (i = 0; i < adapter->uc_macs; i++) {
- if (ether_addr_equal((u8 *)&adapter->uc_list[i * ETH_ALEN],
- mac)) {
+ if (ether_addr_equal(adapter->uc_list[i].mac, mac)) {
/* mac already added, skip addition */
adapter->pmac_id[0] = adapter->pmac_id[i + 1];
return 0;
@@ -1679,14 +1678,12 @@ static void be_clear_mc_list(struct be_a
static int be_uc_mac_add(struct be_adapter *adapter, int uc_idx)
{
- if (ether_addr_equal((u8 *)&adapter->uc_list[uc_idx * ETH_ALEN],
- adapter->dev_mac)) {
+ if (ether_addr_equal(adapter->uc_list[uc_idx].mac, adapter->dev_mac)) {
adapter->pmac_id[uc_idx + 1] = adapter->pmac_id[0];
return 0;
}
- return be_cmd_pmac_add(adapter,
- (u8 *)&adapter->uc_list[uc_idx * ETH_ALEN],
+ return be_cmd_pmac_add(adapter, adapter->uc_list[uc_idx].mac,
adapter->if_handle,
&adapter->pmac_id[uc_idx + 1], 0);
}
Patches currently in stable-queue which might be from cera(a)cera.cz are
queue-4.9/be2net-fix-accesses-to-unicast-list.patch
queue-4.9/be2net-fix-initial-mac-setting.patch
queue-4.9/be2net-fix-unicast-list-filling.patch
On Tue, Dec 05, 2017 at 04:10:59PM +0800, Qu Wenruo wrote:
>
>
> On 2017年12月05日 15:29, Nikolay Borisov wrote:
> > This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers to deal
> > with pages that have been improperly dirtied") and it didn't do any error
> > handling then. This function might very well fail in ENOMEM situation, yet
> > it's not handled, this could lead to inconsistent state. So let's handle the
> > failure by setting the mapping error bit.
> >
> > Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
> > Cc: stable(a)vger.kernel.org
>
> Reviewed-by: Qu Wenruo <wqu(a)suse.com>
>
> That's the only missing one. Nice catch.
You mean the only unhandled call of btrfs_set_extent_delalloc? There's
one more in relocate_file_extent_cluster.
This is a note to let you know that I've just added the patch titled
Revert "ocfs2: should wait dio before inode lock in ocfs2_setattr()"
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:
revert-ocfs2-should-wait-dio-before-inode-lock-in-ocfs2_setattr.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 02b359b1331a9fd96f43028cee5500dfac4454b9 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Wed, 6 Dec 2017 17:33:18 +0100
Subject: Revert "ocfs2: should wait dio before inode lock in ocfs2_setattr()"
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
This reverts commit c4baa4a5870cb02f713def1620052bfca7a82bbb which is
commit 28f5a8a7c033cbf3e32277f4cc9c6afd74f05300 upstream.
It shouldn't be applied to the 4.4-stable tree.
Ben and Alex write:
> Now that ocfs2_setattr() calls this outside of the inode locked region,
> what prevents another task adding a new dio request immediately
> afterward?
>
In the kernel 4.6, firstly, we use the inode_lock() in do_truncate() to
prevent another bio to be issued from this node.
Furthermore, we use the ocfs2_rw_lock() and ocfs2_inode_lock() in ocfs2_setattr()
to guarantee no more bio will be issued from the other nodes in this cluster.
> Also, ocfs2_dio_end_io_write() was introduced in 4.6 and it looks like
> the dio completion path didn't previously take the inode lock. So it
> doesn't look this fix is needed in 3.18 or 4.4.
Yes, ocfs2_dio_end_io_write() was introduced in 4.6 and the problem this patch
fixes is only exist in the kernel 4.6 and above 4.6.
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Cc: Alex Chen <alex.chen(a)huawei.com>
Cc: Jun Piao <piaojun(a)huawei.com>
Cc: Joseph Qi <jiangqi903(a)gmail.com>
Cc: Changwei Ge <ge.changwei(a)h3c.com>
Cc: Mark Fasheh <mfasheh(a)versity.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: Junxiao Bi <junxiao.bi(a)oracle.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ocfs2/file.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1166,13 +1166,6 @@ int ocfs2_setattr(struct dentry *dentry,
}
size_change = S_ISREG(inode->i_mode) && attr->ia_valid & ATTR_SIZE;
if (size_change) {
- /*
- * Here we should wait dio to finish before inode lock
- * to avoid a deadlock between ocfs2_setattr() and
- * ocfs2_dio_end_io_write()
- */
- inode_dio_wait(inode);
-
status = ocfs2_rw_lock(inode, 1);
if (status < 0) {
mlog_errno(status);
@@ -1193,6 +1186,8 @@ int ocfs2_setattr(struct dentry *dentry,
if (status)
goto bail_unlock;
+ inode_dio_wait(inode);
+
if (i_size_read(inode) >= attr->ia_size) {
if (ocfs2_should_order_data(inode)) {
status = ocfs2_begin_ordered_truncate(inode,
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.4/xen-netfront-improve-error-handling-during-initialization.patch
queue-4.4/net-systemport-pad-packet-before-inserting-tsb.patch
queue-4.4/kvm-arm-arm64-fix-occasional-warning-from-the-timer-work-function.patch
queue-4.4/s390-pci-do-not-require-ais-facility.patch
queue-4.4/ima-fix-hash-algorithm-initialization.patch
queue-4.4/usb-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch
queue-4.4/spi-sh-msiof-fix-dma-transfer-size-check.patch
queue-4.4/usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
queue-4.4/net-appletalk-fix-kernel-memory-disclosure.patch
queue-4.4/selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.patch
queue-4.4/nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch
queue-4.4/tipc-fix-cleanup-at-module-unload.patch
queue-4.4/bcache-only-permit-to-recovery-read-error-when-cache-device-is-clean.patch
queue-4.4/ravb-remove-rx-overflow-log-messages.patch
queue-4.4/usb-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.patch
queue-4.4/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
queue-4.4/serial-8250-preserve-dld-for-port_xr17v35x.patch
queue-4.4/arm-omap1-dma-correct-the-number-of-logical-channels.patch
queue-4.4/usb-dwc2-fix-udc-state-tracking.patch
queue-4.4/mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
queue-4.4/dmaengine-pl330-fix-double-lock.patch
queue-4.4/revert-ocfs2-should-wait-dio-before-inode-lock-in-ocfs2_setattr.patch
queue-4.4/bcache-recover-data-from-backing-when-data-is-clean.patch
queue-4.4/perf-test-attr-fix-ignored-test-case-result.patch
queue-4.4/s390-runtime-instrumentation-simplify-task-exit-handling.patch
queue-4.4/serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch
queue-4.4/net-systemport-utilize-skb_put_padto.patch
queue-4.4/usbip-tools-install-all-headers-needed-for-libusbip-development.patch
queue-4.4/serial-8250_pci-add-amazon-pci-serial-device-id.patch
queue-4.4/sysrq-fix-show-regs-call-trace-on-arm.patch
queue-4.4/tcp-correct-memory-barrier-usage-in-tcp_check_space.patch
queue-4.4/net-fec-fix-multicast-filtering-hardware-setup.patch
queue-4.4/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
queue-4.4/uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.patch
queue-4.4/vti6-fix-device-register-to-report-ifla_info_kind.patch
queue-4.4/kprobes-x86-disable-preemption-in-ftrace-based-jprobes.patch
queue-4.4/usb-serial-option-add-quectel-bg96-id.patch
queue-4.4/drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
queue-4.4/edac-sb_edac-fix-missing-break-in-switch.patch
queue-4.4/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
This is a note to let you know that I've just added the patch titled
xen-netfront: Improve error handling during initialization
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:
xen-netfront-improve-error-handling-during-initialization.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Wed, 8 Feb 2017 10:57:37 +0000
Subject: xen-netfront: Improve error handling during initialization
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit e2e004acc7cbe3c531e752a270a74e95cde3ea48 ]
This fixes a crash when running out of grant refs when creating many
queues across many netdevs.
* If creating queues fails (i.e. there are no grant refs available),
call xenbus_dev_fatal() to ensure that the xenbus device is set to the
closed state.
* If no queues are created, don't call xennet_disconnect_backend as
netdev->real_num_tx_queues will not have been set correctly.
* If setup_netfront() fails, ensure that all the queues created are
cleaned up, not just those that have been set up.
* If any queues were set up and an error occurs, call
xennet_destroy_queues() to clean up the napi context.
* If any fatal error occurs, unregister and destroy the netdev to avoid
leaving around a half setup network device.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netfront.c | 29 +++++++++++------------------
1 file changed, 11 insertions(+), 18 deletions(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1840,27 +1840,19 @@ static int talk_to_netback(struct xenbus
xennet_destroy_queues(info);
err = xennet_create_queues(info, &num_queues);
- if (err < 0)
- goto destroy_ring;
+ if (err < 0) {
+ xenbus_dev_fatal(dev, err, "creating queues");
+ kfree(info->queues);
+ info->queues = NULL;
+ goto out;
+ }
/* Create shared ring, alloc event channel -- for each queue */
for (i = 0; i < num_queues; ++i) {
queue = &info->queues[i];
err = setup_netfront(dev, queue, feature_split_evtchn);
- if (err) {
- /* setup_netfront() will tidy up the current
- * queue on error, but we need to clean up
- * those already allocated.
- */
- if (i > 0) {
- rtnl_lock();
- netif_set_real_num_tx_queues(info->netdev, i);
- rtnl_unlock();
- goto destroy_ring;
- } else {
- goto out;
- }
- }
+ if (err)
+ goto destroy_ring;
}
again:
@@ -1950,9 +1942,10 @@ abort_transaction_no_dev_fatal:
xenbus_transaction_end(xbt, 1);
destroy_ring:
xennet_disconnect_backend(info);
- kfree(info->queues);
- info->queues = NULL;
+ xennet_destroy_queues(info);
out:
+ unregister_netdev(info->netdev);
+ xennet_free_netdev(info->netdev);
return err;
}
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-4.4/xen-netfront-improve-error-handling-during-initialization.patch
This is a note to let you know that I've just added the patch titled
x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
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:
x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Dave Hansen <dave.hansen(a)linux.intel.com>
Date: Wed, 18 Oct 2017 10:21:07 -0700
Subject: x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
From: Dave Hansen <dave.hansen(a)linux.intel.com>
[ Upstream commit da20ab35180780e4a6eadc804544f1fa967f3567 ]
We do not have tracepoints for sys_modify_ldt() because we define
it directly instead of using the normal SYSCALL_DEFINEx() macros.
However, there is a reason sys_modify_ldt() does not use the macros:
it has an 'int' return type instead of 'unsigned long'. This is
a bug, but it's a bug cemented in the ABI.
What does this mean? If we return -EINVAL from a function that
returns 'int', we have 0x00000000ffffffea in %rax. But, if we
return -EINVAL from a function returning 'unsigned long', we end
up with 0xffffffffffffffea in %rax, which is wrong.
To work around this and maintain the 'int' behavior while using
the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int'
in both implementations of sys_modify_ldt().
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Reviewed-by: Andy Lutomirski <luto(a)kernel.org>
Reviewed-by: Brian Gerst <brgerst(a)gmail.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20171018172107.1A79C532@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/syscalls.h | 2 +-
arch/x86/kernel/ldt.c | 16 +++++++++++++---
arch/x86/um/ldt.c | 7 +++++--
3 files changed, 19 insertions(+), 6 deletions(-)
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -21,7 +21,7 @@ asmlinkage long sys_ioperm(unsigned long
asmlinkage long sys_iopl(unsigned int);
/* kernel/ldt.c */
-asmlinkage int sys_modify_ldt(int, void __user *, unsigned long);
+asmlinkage long sys_modify_ldt(int, void __user *, unsigned long);
/* kernel/signal.c */
asmlinkage long sys_rt_sigreturn(void);
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -12,6 +12,7 @@
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/smp.h>
+#include <linux/syscalls.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/uaccess.h>
@@ -271,8 +272,8 @@ out:
return error;
}
-asmlinkage int sys_modify_ldt(int func, void __user *ptr,
- unsigned long bytecount)
+SYSCALL_DEFINE3(modify_ldt, int , func , void __user * , ptr ,
+ unsigned long , bytecount)
{
int ret = -ENOSYS;
@@ -290,5 +291,14 @@ asmlinkage int sys_modify_ldt(int func,
ret = write_ldt(ptr, bytecount, 0);
break;
}
- return ret;
+ /*
+ * The SYSCALL_DEFINE() macros give us an 'unsigned long'
+ * return type, but tht ABI for sys_modify_ldt() expects
+ * 'int'. This cast gives us an int-sized value in %rax
+ * for the return code. The 'unsigned' is necessary so
+ * the compiler does not try to sign-extend the negative
+ * return codes into the high half of the register when
+ * taking the value from int->long.
+ */
+ return (unsigned int)ret;
}
--- a/arch/x86/um/ldt.c
+++ b/arch/x86/um/ldt.c
@@ -6,6 +6,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/slab.h>
+#include <linux/syscalls.h>
#include <linux/uaccess.h>
#include <asm/unistd.h>
#include <os.h>
@@ -369,7 +370,9 @@ void free_ldt(struct mm_context *mm)
mm->arch.ldt.entry_count = 0;
}
-int sys_modify_ldt(int func, void __user *ptr, unsigned long bytecount)
+SYSCALL_DEFINE3(modify_ldt, int , func , void __user * , ptr ,
+ unsigned long , bytecount)
{
- return do_modify_ldt_skas(func, ptr, bytecount);
+ /* See non-um modify_ldt() for why we do this cast */
+ return (unsigned int)do_modify_ldt_skas(func, ptr, bytecount);
}
Patches currently in stable-queue which might be from dave.hansen(a)linux.intel.com are
queue-4.4/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
This is a note to let you know that I've just added the patch titled
vti6: fix device register to report IFLA_INFO_KIND
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:
vti6-fix-device-register-to-report-ifla_info_kind.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: David Forster <dforster(a)brocade.com>
Date: Fri, 6 Jan 2017 10:27:59 +0000
Subject: vti6: fix device register to report IFLA_INFO_KIND
From: David Forster <dforster(a)brocade.com>
[ Upstream commit 93e246f783e6bd1bc64fdfbfe68b18161f69b28e ]
vti6 interface is registered before the rtnl_link_ops block
is attached. As a result the resulting RTM_NEWLINK is missing
IFLA_INFO_KIND. Re-order attachment of rtnl_link_ops block to fix.
Signed-off-by: Dave Forster <dforster(a)brocade.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>
---
net/ipv6/ip6_vti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -189,12 +189,12 @@ static int vti6_tnl_create2(struct net_d
struct vti6_net *ip6n = net_generic(net, vti6_net_id);
int err;
+ dev->rtnl_link_ops = &vti6_link_ops;
err = register_netdevice(dev);
if (err < 0)
goto out;
strcpy(t->parms.name, dev->name);
- dev->rtnl_link_ops = &vti6_link_ops;
dev_hold(dev);
vti6_tnl_link(ip6n, t);
Patches currently in stable-queue which might be from dforster(a)brocade.com are
queue-4.4/vti6-fix-device-register-to-report-ifla_info_kind.patch
This is a note to let you know that I've just added the patch titled
USB: serial: option: add Quectel BG96 id
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:
usb-serial-option-add-quectel-bg96-id.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 c654b21ede93845863597de9ad774fd30db5f2ab Mon Sep 17 00:00:00 2001
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
Date: Mon, 20 Nov 2017 19:29:32 +0100
Subject: USB: serial: option: add Quectel BG96 id
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
commit c654b21ede93845863597de9ad774fd30db5f2ab upstream.
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
development board (EVB). The USB id is added to option.c to allow
DIAG,GPS,AT and modem communication with the BG96.
Signed-off-by: Sebastian Sjoholm <ssjoholm(a)mac.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -241,6 +241,7 @@ static void option_instat_callback(struc
/* These Quectel products use Quectel's vendor ID */
#define QUECTEL_PRODUCT_EC21 0x0121
#define QUECTEL_PRODUCT_EC25 0x0125
+#define QUECTEL_PRODUCT_BG96 0x0296
#define CMOTECH_VENDOR_ID 0x16d8
#define CMOTECH_PRODUCT_6001 0x6001
@@ -1185,6 +1186,8 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+ { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
Patches currently in stable-queue which might be from ssjoholm(a)mac.com are
queue-4.4/usb-serial-option-add-quectel-bg96-id.patch
This is a note to let you know that I've just added the patch titled
usbip: tools: Install all headers needed for libusbip development
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:
usbip-tools-install-all-headers-needed-for-libusbip-development.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Ben Hutchings <ben(a)decadent.org.uk>
Date: Sun, 1 Oct 2017 02:18:37 +0100
Subject: usbip: tools: Install all headers needed for libusbip development
From: Ben Hutchings <ben(a)decadent.org.uk>
[ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
usbip_host_driver.h now depends on several additional headers, which
need to be installed along with it.
Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver ...")
Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with ...")
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/tools/usb/usbip/Makefile.am
+++ b/tools/usb/usbip/Makefile.am
@@ -1,6 +1,7 @@
SUBDIRS := libsrc src
includedir = @includedir@/usbip
include_HEADERS := $(addprefix libsrc/, \
- usbip_common.h vhci_driver.h usbip_host_driver.h)
+ usbip_common.h vhci_driver.h usbip_host_driver.h \
+ list.h sysfs_utils.h usbip_host_common.h)
dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8)
Patches currently in stable-queue which might be from ben(a)decadent.org.uk are
queue-4.4/usbip-tools-install-all-headers-needed-for-libusbip-development.patch
This is a note to let you know that I've just added the patch titled
usb: phy: tahvo: fix error handling in tahvo_usb_probe()
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:
usb-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 21 Oct 2017 01:02:07 +0300
Subject: usb: phy: tahvo: fix error handling in tahvo_usb_probe()
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit ce035409bfa892a2fabb89720b542e1b335c3426 ]
If devm_extcon_dev_allocate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Fixes: 860d2686fda7 ("usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API")
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/phy/phy-tahvo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -368,7 +368,8 @@ static int tahvo_usb_probe(struct platfo
tu->extcon = devm_extcon_dev_allocate(&pdev->dev, tahvo_cable);
if (IS_ERR(tu->extcon)) {
dev_err(&pdev->dev, "failed to allocate memory for extcon\n");
- return -ENOMEM;
+ ret = PTR_ERR(tu->extcon);
+ goto err_disable_clk;
}
ret = devm_extcon_dev_register(&pdev->dev, tu->extcon);
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.4/usb-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch
This is a note to let you know that I've just added the patch titled
usb: dwc2: Error out of dwc2_hsotg_ep_disable() if we're in host mode
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:
usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 23 Oct 2017 14:32:49 -0700
Subject: usb: dwc2: Error out of dwc2_hsotg_ep_disable() if we're in host mode
From: John Stultz <john.stultz(a)linaro.org>
[ Upstream commit 9b481092c2a31a6b630aff9c28f0145bf6683787 ]
We've found that while in host mode, using Android, if one runs
the command:
stop adbd
The existing usb devices being utilized in host mode are disconnected.
This is most visible with usb networking devices.
This seems to be due to adbd closing the file:
/dev/usb-ffs/adb/ep0
Which calls ffs_ep0_release() and the following backtrace:
[<ffffff800875a430>] dwc2_hsotg_ep_disable+0x148/0x150
[<ffffff800875a498>] dwc2_hsotg_udc_stop+0x60/0x110
[<ffffff8008787950>] usb_gadget_remove_driver+0x58/0x78
[<ffffff80087879e4>] usb_gadget_unregister_driver+0x74/0xe8
[<ffffff80087850c0>] unregister_gadget+0x28/0x58
[<ffffff800878511c>] unregister_gadget_item+0x2c/0x40
[<ffffff8008790ea8>] ffs_data_clear+0xe8/0xf8
[<ffffff8008790ed8>] ffs_data_reset+0x20/0x58
[<ffffff8008793218>] ffs_data_closed+0x98/0xe8
[<ffffff80087932d8>] ffs_ep0_release+0x20/0x30
Then when dwc2_hsotg_ep_disable() is called, we call
kill_all_requests() which causes a bunch of the following
messages:
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
init: Service 'adbd' (pid 1915) killed by signal 9
init: Sending signal 9 to service 'adbd' (pid 1915) process group...
init: Successfully killed process cgroup uid 0 pid 1915 in 0ms
init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:15)
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_update_urb_state_abn(): trimming xfer length
And the usb devices connected are basically hung at this point.
It seems like if we're in host mode, we probably shouldn't run
the dwc2_hostg_ep_disable logic, so this patch returns an error
in that case.
With this patch (along with the previous patch in this set), we avoid
the mismatched interrupts and connected usb devices continue to function.
I'm not sure if some other solution would be better here, but this seems
to work, so I wanted to send it out for input on what the right approach
should be.
Cc: Wei Xu <xuwei5(a)hisilicon.com>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: YongQin Liu <yongqin.liu(a)linaro.org>
Cc: John Youn <johnyoun(a)synopsys.com>
Cc: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Cc: Douglas Anderson <dianders(a)chromium.org>
Cc: Chen Yu <chenyu56(a)huawei.com>
Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: linux-usb(a)vger.kernel.org
Acked-by: Minas Harutyunyan <hminas(a)synopsys.com>
Tested-by: Minas Harutyunyan <hminas(a)synopsys.com>
Reported-by: YongQin Liu <yongqin.liu(a)linaro.org>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/gadget.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2834,6 +2834,11 @@ static int dwc2_hsotg_ep_disable(struct
return -EINVAL;
}
+ if (hsotg->op_state != OTG_STATE_B_PERIPHERAL) {
+ dev_err(hsotg->dev, "%s: called in host mode?\n", __func__);
+ return -EINVAL;
+ }
+
epctrl_reg = dir_in ? DIEPCTL(index) : DOEPCTL(index);
spin_lock_irqsave(&hsotg->lock, flags);
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.4/usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
queue-4.4/usb-dwc2-fix-udc-state-tracking.patch
This is a note to let you know that I've just added the patch titled
usb: dwc2: Fix UDC state tracking
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:
usb-dwc2-fix-udc-state-tracking.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 23 Oct 2017 14:32:50 -0700
Subject: usb: dwc2: Fix UDC state tracking
From: John Stultz <john.stultz(a)linaro.org>
[ Upstream commit ce2b21a4e5ce042c0a42c9db8fa9e0f849427d5e ]
It has been noticed that the dwc2 udc state reporting doesn't
seem to work (at least on HiKey boards). Where after the initial
setup, the sysfs /sys/class/udc/f72c0000.usb/state file would
report "configured" no matter the state of the OTG port.
This patch adds a call so that we report to the UDC layer when
the gadget device is disconnected.
This patch does depend on the previous patch ("usb: dwc2:
Improve gadget state disconnection handling") in this patch set
in order to properly work.
Cc: Wei Xu <xuwei5(a)hisilicon.com>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: YongQin Liu <yongqin.liu(a)linaro.org>
Cc: John Youn <johnyoun(a)synopsys.com>
Cc: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Cc: Douglas Anderson <dianders(a)chromium.org>
Cc: Chen Yu <chenyu56(a)huawei.com>
Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: linux-usb(a)vger.kernel.org
Acked-by: Minas Harutyunyan <hminas(a)synopsys.com>
Tested-by: Minas Harutyunyan <hminas(a)synopsys.com>
Reported-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2206,6 +2206,8 @@ void dwc2_hsotg_disconnect(struct dwc2_h
call_gadget(hsotg, disconnect);
hsotg->lx_state = DWC2_L3;
+
+ usb_gadget_set_state(&hsotg->gadget, USB_STATE_NOTATTACHED);
}
/**
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.4/usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
queue-4.4/usb-dwc2-fix-udc-state-tracking.patch
This is a note to let you know that I've just added the patch titled
tipc: fix cleanup at module unload
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:
tipc-fix-cleanup-at-module-unload.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com>
Date: Tue, 24 Jan 2017 13:00:48 +0100
Subject: tipc: fix cleanup at module unload
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com>
[ Upstream commit 35e22e49a5d6a741ebe7f2dd280b2052c3003ef7 ]
In tipc_server_stop(), we iterate over the connections with limiting
factor as server's idr_in_use. We ignore the fact that this variable
is decremented in tipc_close_conn(), leading to premature exit.
In this commit, we iterate until the we have no connections left.
Acked-by: Ying Xue <ying.xue(a)windriver.com>
Acked-by: Jon Maloy <jon.maloy(a)ericsson.com>
Tested-by: John Thompson <thompa.atl(a)gmail.com>
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.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>
---
net/tipc/server.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/net/tipc/server.c
+++ b/net/tipc/server.c
@@ -618,14 +618,12 @@ int tipc_server_start(struct tipc_server
void tipc_server_stop(struct tipc_server *s)
{
struct tipc_conn *con;
- int total = 0;
int id;
spin_lock_bh(&s->idr_lock);
- for (id = 0; total < s->idr_in_use; id++) {
+ for (id = 0; s->idr_in_use; id++) {
con = idr_find(&s->conn_idr, id);
if (con) {
- total++;
spin_unlock_bh(&s->idr_lock);
tipc_close_conn(con);
spin_lock_bh(&s->idr_lock);
Patches currently in stable-queue which might be from parthasarathy.bhuvaragan(a)ericsson.com are
queue-4.4/tipc-fix-cleanup-at-module-unload.patch
This is a note to let you know that I've just added the patch titled
sysrq : fix Show Regs call trace on ARM
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:
sysrq-fix-show-regs-call-trace-on-arm.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Jibin Xu <jibin.xu(a)windriver.com>
Date: Sun, 10 Sep 2017 20:11:42 -0700
Subject: sysrq : fix Show Regs call trace on ARM
From: Jibin Xu <jibin.xu(a)windriver.com>
[ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]
When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 >/proc/sys/kernel/sysrq
echo p >/proc/sysrq-trigger
kernel will print call trace as below:
sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[<ffffff8008088e80>] dump_backtrace+0x0/0x1d0
[<ffffff8008089074>] show_stack+0x24/0x30
[<ffffff8008447970>] dump_stack+0x90/0xb0
[<ffffff8008463950>] check_preemption_disabled+0x100/0x108
[<ffffff8008463998>] __this_cpu_preempt_check+0x18/0x20
[<ffffff80084c9194>] sysrq_handle_showregs+0x1c/0x40
[<ffffff80084c9c7c>] __handle_sysrq+0x12c/0x1a0
[<ffffff80084ca140>] write_sysrq_trigger+0x60/0x70
[<ffffff8008251e00>] proc_reg_write+0x90/0xd0
[<ffffff80081f1788>] __vfs_write+0x48/0x90
[<ffffff80081f241c>] vfs_write+0xa4/0x190
[<ffffff80081f3354>] SyS_write+0x54/0xb0
[<ffffff80080833f0>] el0_svc_naked+0x24/0x28
This can be seen on a common board like an r-pi3.
This happens because when echo p >/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.
Signed-off-by: Jibin Xu <jibin.xu(a)windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/sysrq.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -237,8 +237,10 @@ static void sysrq_handle_showallcpus(int
* architecture has no support for it:
*/
if (!trigger_all_cpu_backtrace()) {
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+ if (in_irq())
+ regs = get_irq_regs();
if (regs) {
pr_info("CPU%d:\n", smp_processor_id());
show_regs(regs);
@@ -257,7 +259,10 @@ static struct sysrq_key_op sysrq_showall
static void sysrq_handle_showregs(int key)
{
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+
+ if (in_irq())
+ regs = get_irq_regs();
if (regs)
show_regs(regs);
perf_event_print_debug();
Patches currently in stable-queue which might be from jibin.xu(a)windriver.com are
queue-4.4/sysrq-fix-show-regs-call-trace-on-arm.patch
This is a note to let you know that I've just added the patch titled
tcp: correct memory barrier usage in tcp_check_space()
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:
tcp-correct-memory-barrier-usage-in-tcp_check_space.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Jason Baron <jbaron(a)akamai.com>
Date: Tue, 24 Jan 2017 21:49:41 -0500
Subject: tcp: correct memory barrier usage in tcp_check_space()
From: Jason Baron <jbaron(a)akamai.com>
[ Upstream commit 56d806222ace4c3aeae516cd7a855340fb2839d8 ]
sock_reset_flag() maps to __clear_bit() not the atomic version clear_bit().
Thus, we need smp_mb(), smp_mb__after_atomic() is not sufficient.
Fixes: 3c7151275c0c ("tcp: add memory barriers to write space paths")
Cc: Eric Dumazet <eric.dumazet(a)gmail.com>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Signed-off-by: Jason Baron <jbaron(a)akamai.com>
Acked-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Oleg Nesterov <oleg(a)redhat.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>
---
net/ipv4/tcp_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4942,7 +4942,7 @@ static void tcp_check_space(struct sock
if (sock_flag(sk, SOCK_QUEUE_SHRUNK)) {
sock_reset_flag(sk, SOCK_QUEUE_SHRUNK);
/* pairs with tcp_poll() */
- smp_mb__after_atomic();
+ smp_mb();
if (sk->sk_socket &&
test_bit(SOCK_NOSPACE, &sk->sk_socket->flags))
tcp_new_space(sk);
Patches currently in stable-queue which might be from jbaron(a)akamai.com are
queue-4.4/tcp-correct-memory-barrier-usage-in-tcp_check_space.patch
This is a note to let you know that I've just added the patch titled
spi: sh-msiof: Fix DMA transfer size check
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:
spi-sh-msiof-fix-dma-transfer-size-check.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Date: Thu, 2 Nov 2017 10:32:36 +0100
Subject: spi: sh-msiof: Fix DMA transfer size check
From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support")
Signed-off-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Dirk Behme <dirk.behme(a)de.bosch.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-sh-msiof.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -863,7 +863,7 @@ static int sh_msiof_transfer_one(struct
break;
copy32 = copy_bswap32;
} else if (bits <= 16) {
- if (l & 1)
+ if (l & 3)
break;
copy32 = copy_wswap32;
} else {
Patches currently in stable-queue which might be from hiromitsu.yamasaki.ym(a)renesas.com are
queue-4.4/spi-sh-msiof-fix-dma-transfer-size-check.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
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:
serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sat, 28 Oct 2017 11:35:49 +0200
Subject: serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
From: Lukas Wunner <lukas(a)wunner.de>
[ Upstream commit 3236a965486ba0c6043cf2c7b51943d8b382ae29 ]
This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND
and SER_RS485_RTS_AFTER_SEND have the same value. If they do, it means
the user has passed in invalid data with the TIOCSRS485 ioctl()
since RTS must have a different polarity when sending and when not
sending. In this case, rs485 mode is not enabled (the RS485_URA bit
is not set in the RS485 Enable Register) and this is supposed to be
signaled back to the user by clearing the SER_RS485_ENABLED bit in
struct serial_rs485 ... except a missing tilde character is preventing
that from happening.
Fixes: 28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART")
Cc: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Cc: "Ji-Ze Hong (Peter Hong)" <hpeter(a)gmail.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_fintek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/8250/8250_fintek.c
+++ b/drivers/tty/serial/8250/8250_fintek.c
@@ -117,7 +117,7 @@ static int fintek_8250_rs485_config(stru
if ((!!(rs485->flags & SER_RS485_RTS_ON_SEND)) ==
(!!(rs485->flags & SER_RS485_RTS_AFTER_SEND)))
- rs485->flags &= SER_RS485_ENABLED;
+ rs485->flags &= ~SER_RS485_ENABLED;
else
config |= RS485_URA;
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.4/serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch
This is a note to let you know that I've just added the patch titled
selftests/x86/ldt_get: Add a few additional tests for limits
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:
selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Andy Lutomirski <luto(a)kernel.org>
Date: Sat, 4 Nov 2017 04:19:52 -0700
Subject: selftests/x86/ldt_get: Add a few additional tests for limits
From: Andy Lutomirski <luto(a)kernel.org>
[ Upstream commit fec8f5ae1715a01c72ad52cb2ecd8aacaf142302 ]
We weren't testing the .limit and .limit_in_pages fields very well.
Add more tests.
This addition seems to trigger the "bits 16:19 are undefined" issue
that was fixed in an earlier patch. I think that, at least on my
CPU, the high nibble of the limit ends in LAR bits 16:19.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bpetkov(a)suse.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/5601c15ea9b3113d288953fd2838b18bedf6bc67.150979432…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/x86/ldt_gdt.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
--- a/tools/testing/selftests/x86/ldt_gdt.c
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -351,9 +351,24 @@ static void do_simple_tests(void)
install_invalid(&desc, false);
desc.seg_not_present = 0;
- desc.read_exec_only = 0;
desc.seg_32bit = 1;
+ desc.read_exec_only = 0;
+ desc.limit = 0xfffff;
+
install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA | AR_S | AR_P | AR_DB);
+
+ desc.limit_in_pages = 1;
+
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA | AR_S | AR_P | AR_DB | AR_G);
+ desc.read_exec_only = 1;
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RODATA | AR_S | AR_P | AR_DB | AR_G);
+ desc.contents = 1;
+ desc.read_exec_only = 0;
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RWDATA_EXPDOWN | AR_S | AR_P | AR_DB | AR_G);
+ desc.read_exec_only = 1;
+ install_valid(&desc, AR_DPL3 | AR_TYPE_RODATA_EXPDOWN | AR_S | AR_P | AR_DB | AR_G);
+
+ desc.limit = 0;
install_invalid(&desc, true);
}
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.4/selftests-x86-ldt_get-add-a-few-additional-tests-for-limits.patch
queue-4.4/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
This is a note to let you know that I've just added the patch titled
serial: 8250: Preserve DLD[7:4] for PORT_XR17V35X
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:
serial-8250-preserve-dld-for-port_xr17v35x.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Aaron Sierra <asierra(a)xes-inc.com>
Date: Wed, 4 Oct 2017 10:01:28 -0500
Subject: serial: 8250: Preserve DLD[7:4] for PORT_XR17V35X
From: Aaron Sierra <asierra(a)xes-inc.com>
[ Upstream commit 0ab84da2e076948c49d36197ee7d254125c53eab ]
The upper four bits of the XR17V35x fractional divisor register (DLD)
control general chip function (RS-485 direction pin polarity, multidrop
mode, XON/XOFF parity check, and fast IR mode). Don't allow these bits
to be clobbered when setting the baudrate.
Signed-off-by: Aaron Sierra <asierra(a)xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2223,8 +2223,11 @@ static void serial8250_set_divisor(struc
serial_dl_write(up, quot);
/* XR17V35x UARTs have an extra fractional divisor register (DLD) */
- if (up->port.type == PORT_XR17V35X)
+ if (up->port.type == PORT_XR17V35X) {
+ /* Preserve bits not related to baudrate; DLD[7:4]. */
+ quot_frac |= serial_port_in(port, 0x2) & 0xf0;
serial_port_out(port, 0x2, quot_frac);
+ }
}
static unsigned int
Patches currently in stable-queue which might be from asierra(a)xes-inc.com are
queue-4.4/serial-8250-preserve-dld-for-port_xr17v35x.patch
This is a note to let you know that I've just added the patch titled
s390/pci: do not require AIS facility
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:
s390-pci-do-not-require-ais-facility.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
Date: Mon, 30 Oct 2017 14:38:58 +0100
Subject: s390/pci: do not require AIS facility
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
[ Upstream commit 48070c73058be6de9c0d754d441ed7092dfc8f12 ]
As of today QEMU does not provide the AIS facility to its guest. This
prevents Linux guests from using PCI devices as the ais facility is
checked during init. As this is just a performance optimization, we can
move the ais check into the code where we need it (calling the SIC
instruction). This is used at initialization and on interrupt. Both
places do not require any serialization, so we can simply skip the
instruction.
Since we will now get all interrupts, we can also avoid the 2nd scan.
As we can have multiple interrupts in parallel we might trigger spurious
irqs more often for the non-AIS case but the core code can handle that.
Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Reviewed-by: Pierre Morel <pmorel(a)linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic(a)linux.vnet.ibm.com>
Acked-by: Sebastian Ott <sebott(a)linux.vnet.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/include/asm/pci_insn.h | 2 +-
arch/s390/pci/pci.c | 5 +++--
arch/s390/pci/pci_insn.c | 6 +++++-
3 files changed, 9 insertions(+), 4 deletions(-)
--- a/arch/s390/include/asm/pci_insn.h
+++ b/arch/s390/include/asm/pci_insn.h
@@ -81,6 +81,6 @@ int zpci_refresh_trans(u64 fn, u64 addr,
int zpci_load(u64 *data, u64 req, u64 offset);
int zpci_store(u64 data, u64 req, u64 offset);
int zpci_store_block(const u64 *data, u64 req, u64 offset);
-void zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc);
+int zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc);
#endif
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -359,7 +359,8 @@ static void zpci_irq_handler(struct airq
/* End of second scan with interrupts on. */
break;
/* First scan complete, reenable interrupts. */
- zpci_set_irq_ctrl(SIC_IRQ_MODE_SINGLE, NULL, PCI_ISC);
+ if (zpci_set_irq_ctrl(SIC_IRQ_MODE_SINGLE, NULL, PCI_ISC))
+ break;
si = 0;
continue;
}
@@ -921,7 +922,7 @@ static int __init pci_base_init(void)
if (!s390_pci_probe)
return 0;
- if (!test_facility(69) || !test_facility(71) || !test_facility(72))
+ if (!test_facility(69) || !test_facility(71))
return 0;
rc = zpci_debug_init();
--- a/arch/s390/pci/pci_insn.c
+++ b/arch/s390/pci/pci_insn.c
@@ -7,6 +7,7 @@
#include <linux/export.h>
#include <linux/errno.h>
#include <linux/delay.h>
+#include <asm/facility.h>
#include <asm/pci_insn.h>
#include <asm/pci_debug.h>
#include <asm/processor.h>
@@ -91,11 +92,14 @@ int zpci_refresh_trans(u64 fn, u64 addr,
}
/* Set Interruption Controls */
-void zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc)
+int zpci_set_irq_ctrl(u16 ctl, char *unused, u8 isc)
{
+ if (!test_facility(72))
+ return -EIO;
asm volatile (
" .insn rsy,0xeb00000000d1,%[ctl],%[isc],%[u]\n"
: : [ctl] "d" (ctl), [isc] "d" (isc << 27), [u] "Q" (*unused));
+ return 0;
}
/* PCI Load */
Patches currently in stable-queue which might be from borntraeger(a)de.ibm.com are
queue-4.4/s390-pci-do-not-require-ais-facility.patch
This is a note to let you know that I've just added the patch titled
perf test attr: Fix ignored test case result
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:
perf-test-attr-fix-ignored-test-case-result.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
Date: Wed, 13 Sep 2017 10:12:09 +0200
Subject: perf test attr: Fix ignored test case result
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
[ Upstream commit 22905582f6dd4bbd0c370fe5732c607452010c04 ]
Command perf test -v 16 (Setup struct perf_event_attr test) always
reports success even if the test case fails. It works correctly if you
also specify -F (for don't fork).
root@s35lp76 perf]# ./perf test -v 16
15: Setup struct perf_event_attr :
--- start ---
running './tests/attr/test-record-no-delay'
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB /tmp/tmp4E1h7R/perf.data
(1 samples) ]
expected task=0, got 1
expected precise_ip=0, got 3
expected wakeup_events=1, got 0
FAILED './tests/attr/test-record-no-delay' - match failure
test child finished with 0
---- end ----
Setup struct perf_event_attr: Ok
The reason for the wrong error reporting is the return value of the
system() library call. It is called in run_dir() file tests/attr.c and
returns the exit status, in above case 0xff00.
This value is given as parameter to the exit() function which can only
handle values 0-0xff.
The child process terminates with exit value of 0 and the parent does
not detect any error.
This patch corrects the error reporting and prints the correct test
result.
Signed-off-by: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Cc: Hendrik Brueckner <brueckner(a)linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Cc: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
LPU-Reference: 20170913081209.39570-2-tmricht(a)linux.vnet.ibm.com
Link: http://lkml.kernel.org/n/tip-rdube6rfcjsr1nzue72c7lqn@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/tests/attr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -150,7 +150,7 @@ static int run_dir(const char *d, const
snprintf(cmd, 3*PATH_MAX, PYTHON " %s/attr.py -d %s/attr/ -p %s %.*s",
d, d, perf, vcnt, v);
- return system(cmd);
+ return system(cmd) ? TEST_FAIL : TEST_OK;
}
int test__attr(void)
Patches currently in stable-queue which might be from tmricht(a)linux.vnet.ibm.com are
queue-4.4/perf-test-attr-fix-ignored-test-case-result.patch
This is a note to let you know that I've just added the patch titled
ravb: Remove Rx overflow log messages
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:
ravb-remove-rx-overflow-log-messages.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Kazuya Mizuguchi <kazuya.mizuguchi.ks(a)renesas.com>
Date: Thu, 12 Jan 2017 13:21:06 +0100
Subject: ravb: Remove Rx overflow log messages
From: Kazuya Mizuguchi <kazuya.mizuguchi.ks(a)renesas.com>
[ Upstream commit 18a3ed59d09cf81a6447aadf6931bf0c9ffec5e0 ]
Remove Rx overflow log messages as in an environment where logging results
in network traffic logging may cause further overflows.
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks(a)renesas.com>
[simon: reworked changelog]
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/renesas/ravb_main.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -831,14 +831,10 @@ static int ravb_poll(struct napi_struct
/* Receive error message handling */
priv->rx_over_errors = priv->stats[RAVB_BE].rx_over_errors;
priv->rx_over_errors += priv->stats[RAVB_NC].rx_over_errors;
- if (priv->rx_over_errors != ndev->stats.rx_over_errors) {
+ if (priv->rx_over_errors != ndev->stats.rx_over_errors)
ndev->stats.rx_over_errors = priv->rx_over_errors;
- netif_err(priv, rx_err, ndev, "Receive Descriptor Empty\n");
- }
- if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors) {
+ if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors)
ndev->stats.rx_fifo_errors = priv->rx_fifo_errors;
- netif_err(priv, rx_err, ndev, "Receive FIFO Overflow\n");
- }
out:
return budget - quota;
}
Patches currently in stable-queue which might be from kazuya.mizuguchi.ks(a)renesas.com are
queue-4.4/ravb-remove-rx-overflow-log-messages.patch
This is a note to let you know that I've just added the patch titled
NFSv4: Fix client recovery when server reboots multiple times
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:
nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Fri, 13 Jan 2017 13:31:32 -0500
Subject: NFSv4: Fix client recovery when server reboots multiple times
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit c6180a6237174f481dc856ed6e890d8196b6f0fb ]
If the server reboots multiple times, the client should rely on the
server to tell it that it cannot reclaim state as per section 9.6.3.4
in RFC7530 and section 8.4.2.1 in RFC5661.
Currently, the client is being to conservative, and is assuming that
if the server reboots while state recovery is in progress, then it must
ignore state that was not recovered before the reboot.
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4state.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -1680,7 +1680,6 @@ static int nfs4_recovery_handle_error(st
break;
case -NFS4ERR_STALE_CLIENTID:
set_bit(NFS4CLNT_LEASE_EXPIRED, &clp->cl_state);
- nfs4_state_clear_reclaim_reboot(clp);
nfs4_state_start_reclaim_reboot(clp);
break;
case -NFS4ERR_EXPIRED:
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.4/nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch
queue-4.4/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
This is a note to let you know that I've just added the patch titled
nfs: Don't take a reference on fl->fl_file for LOCK operation
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:
nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Benjamin Coddington <bcodding(a)redhat.com>
Date: Thu, 5 Jan 2017 10:20:16 -0500
Subject: nfs: Don't take a reference on fl->fl_file for LOCK operation
From: Benjamin Coddington <bcodding(a)redhat.com>
[ Upstream commit 4b09ec4b14a168bf2c687e1f598140c3c11e9222 ]
I have reports of a crash that look like __fput() was called twice for
a NFSv4.0 file. It seems possible that the state manager could try to
reclaim a lock and take a reference on the fl->fl_file at the same time the
file is being released if, during the close(), a signal interrupts the wait
for outstanding IO while removing locks which then skips the removal
of that lock.
Since 83bfff23e9ed ("nfs4: have do_vfs_lock take an inode pointer") has
removed the need to traverse fl->fl_file->f_inode in nfs4_lock_done(),
taking that reference is no longer necessary.
Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com>
Reviewed-by: Jeff Layton <jlayton(a)redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4proc.c | 3 ---
1 file changed, 3 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -38,7 +38,6 @@
#include <linux/mm.h>
#include <linux/delay.h>
#include <linux/errno.h>
-#include <linux/file.h>
#include <linux/string.h>
#include <linux/ratelimit.h>
#include <linux/printk.h>
@@ -5738,7 +5737,6 @@ static struct nfs4_lockdata *nfs4_alloc_
p->server = server;
atomic_inc(&lsp->ls_count);
p->ctx = get_nfs_open_context(ctx);
- get_file(fl->fl_file);
memcpy(&p->fl, fl, sizeof(p->fl));
return p;
out_free_seqid:
@@ -5851,7 +5849,6 @@ static void nfs4_lock_release(void *call
nfs_free_seqid(data->arg.lock_seqid);
nfs4_put_lock_state(data->lsp);
put_nfs_open_context(data->ctx);
- fput(data->fl.fl_file);
kfree(data);
dprintk("%s: done!\n", __func__);
}
Patches currently in stable-queue which might be from bcodding(a)redhat.com are
queue-4.4/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
This is a note to let you know that I've just added the patch titled
net: systemport: Utilize skb_put_padto()
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:
net-systemport-utilize-skb_put_padto.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Tue, 3 Jan 2017 16:34:48 -0800
Subject: net: systemport: Utilize skb_put_padto()
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit bb7da333d0a9f3bddc08f84187b7579a3f68fd24 ]
Since we need to pad our packets, utilize skb_put_padto() which
increases skb->len by how much we need to pad, allowing us to eliminate
the test on skb->len right below.
Signed-off-by: Florian Fainelli <f.fainelli(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/net/ethernet/broadcom/bcmsysport.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1061,13 +1061,12 @@ static netdev_tx_t bcm_sysport_xmit(stru
* (including FCS and tag) because the length verification is done after
* the Broadcom tag is stripped off the ingress packet.
*/
- if (skb_padto(skb, ETH_ZLEN + ENET_BRCM_TAG_LEN)) {
+ if (skb_put_padto(skb, ETH_ZLEN + ENET_BRCM_TAG_LEN)) {
ret = NETDEV_TX_OK;
goto out;
}
- skb_len = skb->len < ETH_ZLEN + ENET_BRCM_TAG_LEN ?
- ETH_ZLEN + ENET_BRCM_TAG_LEN : skb->len;
+ skb_len = skb->len;
mapping = dma_map_single(kdev, skb->data, skb_len, DMA_TO_DEVICE);
if (dma_mapping_error(kdev, mapping)) {
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.4/net-systemport-pad-packet-before-inserting-tsb.patch
queue-4.4/net-systemport-utilize-skb_put_padto.patch
This is a note to let you know that I've just added the patch titled
net: sctp: fix array overrun read on sctp_timer_tbl
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:
net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 20 Jan 2017 13:01:57 +0000
Subject: net: sctp: fix array overrun read on sctp_timer_tbl
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 0e73fc9a56f22f2eec4d2b2910c649f7af67b74d ]
The comparison on the timeout can lead to an array overrun
read on sctp_timer_tbl because of an off-by-one error. Fix
this by using < instead of <= and also compare to the array
size rather than SCTP_EVENT_TIMEOUT_MAX.
Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
Signed-off-by: Colin Ian King <colin.king(a)canonical.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>
---
net/sctp/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sctp/debug.c
+++ b/net/sctp/debug.c
@@ -166,7 +166,7 @@ static const char *const sctp_timer_tbl[
/* Lookup timer debug name. */
const char *sctp_tname(const sctp_subtype_t id)
{
- if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
+ if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
return sctp_timer_tbl[id.timeout];
return "unknown_timer";
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.4/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
This is a note to let you know that I've just added the patch titled
net: systemport: Pad packet before inserting TSB
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:
net-systemport-pad-packet-before-inserting-tsb.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Tue, 3 Jan 2017 16:34:49 -0800
Subject: net: systemport: Pad packet before inserting TSB
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit 38e5a85562a6cd911fc26d951d576551a688574c ]
Inserting the TSB means adding an extra 8 bytes in front the of packet
that is going to be used as metadata information by the TDMA engine, but
stripped off, so it does not really help with the packet padding.
For some odd packet sizes that fall below the 60 bytes payload (e.g: ARP)
we can end-up padding them after the TSB insertion, thus making them 64
bytes, but with the TDMA stripping off the first 8 bytes, they could
still be smaller than 64 bytes which is required to ingress the switch.
Fix this by swapping the padding and TSB insertion, guaranteeing that
the packets have the right sizes.
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Florian Fainelli <f.fainelli(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/net/ethernet/broadcom/bcmsysport.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1045,15 +1045,6 @@ static netdev_tx_t bcm_sysport_xmit(stru
goto out;
}
- /* Insert TSB and checksum infos */
- if (priv->tsb_en) {
- skb = bcm_sysport_insert_tsb(skb, dev);
- if (!skb) {
- ret = NETDEV_TX_OK;
- goto out;
- }
- }
-
/* The Ethernet switch we are interfaced with needs packets to be at
* least 64 bytes (including FCS) otherwise they will be discarded when
* they enter the switch port logic. When Broadcom tags are enabled, we
@@ -1066,6 +1057,15 @@ static netdev_tx_t bcm_sysport_xmit(stru
goto out;
}
+ /* Insert TSB and checksum infos */
+ if (priv->tsb_en) {
+ skb = bcm_sysport_insert_tsb(skb, dev);
+ if (!skb) {
+ ret = NETDEV_TX_OK;
+ goto out;
+ }
+ }
+
skb_len = skb->len;
mapping = dma_map_single(kdev, skb->data, skb_len, DMA_TO_DEVICE);
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.4/net-systemport-pad-packet-before-inserting-tsb.patch
queue-4.4/net-systemport-utilize-skb_put_padto.patch
This is a note to let you know that I've just added the patch titled
net: fec: fix multicast filtering hardware setup
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:
net-fec-fix-multicast-filtering-hardware-setup.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Rui Sousa <rui.sousa(a)nxp.com>
Date: Mon, 13 Feb 2017 10:01:25 +0800
Subject: net: fec: fix multicast filtering hardware setup
From: Rui Sousa <rui.sousa(a)nxp.com>
[ Upstream commit 01f8902bcf3ff124d0aeb88a774180ebcec20ace ]
Fix hardware setup of multicast address hash:
- Never clear the hardware hash (to avoid packet loss)
- Construct the hash register values in software and then write once
to hardware
Signed-off-by: Rui Sousa <rui.sousa(a)nxp.com>
Signed-off-by: Fugang Duan <fugang.duan(a)nxp.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/fec_main.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2968,6 +2968,7 @@ static void set_multicast_list(struct ne
struct netdev_hw_addr *ha;
unsigned int i, bit, data, crc, tmp;
unsigned char hash;
+ unsigned int hash_high = 0, hash_low = 0;
if (ndev->flags & IFF_PROMISC) {
tmp = readl(fep->hwp + FEC_R_CNTRL);
@@ -2990,11 +2991,7 @@ static void set_multicast_list(struct ne
return;
}
- /* Clear filter and add the addresses in hash register
- */
- writel(0, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- writel(0, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
-
+ /* Add the addresses in hash register */
netdev_for_each_mc_addr(ha, ndev) {
/* calculate crc32 value of mac address */
crc = 0xffffffff;
@@ -3012,16 +3009,14 @@ static void set_multicast_list(struct ne
*/
hash = (crc >> (32 - HASH_BITS)) & 0x3f;
- if (hash > 31) {
- tmp = readl(fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- tmp |= 1 << (hash - 32);
- writel(tmp, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- } else {
- tmp = readl(fep->hwp + FEC_GRP_HASH_TABLE_LOW);
- tmp |= 1 << hash;
- writel(tmp, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
- }
+ if (hash > 31)
+ hash_high |= 1 << (hash - 32);
+ else
+ hash_low |= 1 << hash;
}
+
+ writel(hash_high, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
+ writel(hash_low, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
}
/* Set a MAC change in hardware. */
Patches currently in stable-queue which might be from rui.sousa(a)nxp.com are
queue-4.4/net-fec-fix-multicast-filtering-hardware-setup.patch
This is a note to let you know that I've just added the patch titled
mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers
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:
mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Wed, 8 Feb 2017 14:30:53 -0800
Subject: mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers
From: Jan Kara <jack(a)suse.cz>
[ Upstream commit 0911d0041c22922228ca52a977d7b0b0159fee4b ]
Some ->page_mkwrite handlers may return VM_FAULT_RETRY as its return
code (GFS2 or Lustre can definitely do this). However VM_FAULT_RETRY
from ->page_mkwrite is completely unhandled by the mm code and results
in locking and writeably mapping the page which definitely is not what
the caller wanted.
Fix Lustre and block_page_mkwrite_ret() used by other filesystems
(notably GFS2) to return VM_FAULT_NOPAGE instead which results in
bailing out from the fault code, the CPU then retries the access, and we
fault again effectively doing what the handler wanted.
Link: http://lkml.kernel.org/r/20170203150729.15863-1-jack@suse.cz
Signed-off-by: Jan Kara <jack(a)suse.cz>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Reviewed-by: Jinshan Xiong <jinshan.xiong(a)intel.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
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/staging/lustre/lustre/llite/llite_mmap.c | 4 +---
include/linux/buffer_head.h | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/staging/lustre/lustre/llite/llite_mmap.c
+++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c
@@ -402,15 +402,13 @@ static int ll_page_mkwrite(struct vm_are
result = VM_FAULT_LOCKED;
break;
case -ENODATA:
+ case -EAGAIN:
case -EFAULT:
result = VM_FAULT_NOPAGE;
break;
case -ENOMEM:
result = VM_FAULT_OOM;
break;
- case -EAGAIN:
- result = VM_FAULT_RETRY;
- break;
default:
result = VM_FAULT_SIGBUS;
break;
--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -234,12 +234,10 @@ static inline int block_page_mkwrite_ret
{
if (err == 0)
return VM_FAULT_LOCKED;
- if (err == -EFAULT)
+ if (err == -EFAULT || err == -EAGAIN)
return VM_FAULT_NOPAGE;
if (err == -ENOMEM)
return VM_FAULT_OOM;
- if (err == -EAGAIN)
- return VM_FAULT_RETRY;
/* -ENOSPC, -EDQUOT, -EIO ... */
return VM_FAULT_SIGBUS;
}
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.4/mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
This is a note to let you know that I've just added the patch titled
net/appletalk: Fix kernel memory disclosure
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:
net-appletalk-fix-kernel-memory-disclosure.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net>
Date: Mon, 9 Jan 2017 20:57:48 +0700
Subject: net/appletalk: Fix kernel memory disclosure
From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net>
[ Upstream commit ce7e40c432ba84da104438f6799d460a4cad41bc ]
ipddp_route structs contain alignment padding so kernel heap memory
is leaked when they are copied to user space in
ipddp_ioctl(SIOCFINDIPDDPRT). Change kmalloc() to kzalloc() to clear
that memory.
Signed-off-by: Vlad Tsyrklevich <vlad(a)tsyrklevich.net>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/appletalk/ipddp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/appletalk/ipddp.c
+++ b/drivers/net/appletalk/ipddp.c
@@ -191,7 +191,7 @@ static netdev_tx_t ipddp_xmit(struct sk_
*/
static int ipddp_create(struct ipddp_route *new_rt)
{
- struct ipddp_route *rt = kmalloc(sizeof(*rt), GFP_KERNEL);
+ struct ipddp_route *rt = kzalloc(sizeof(*rt), GFP_KERNEL);
if (rt == NULL)
return -ENOMEM;
Patches currently in stable-queue which might be from vlad(a)tsyrklevich.net are
queue-4.4/net-appletalk-fix-kernel-memory-disclosure.patch
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: Fix occasional warning from the timer work function
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:
kvm-arm-arm64-fix-occasional-warning-from-the-timer-work-function.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Christoffer Dall <christoffer.dall(a)linaro.org>
Date: Mon, 9 Jan 2017 12:18:56 +0100
Subject: KVM: arm/arm64: Fix occasional warning from the timer work function
From: Christoffer Dall <christoffer.dall(a)linaro.org>
[ Upstream commit 63e41226afc3f7a044b70325566fa86ac3142538 ]
When a VCPU blocks (WFI) and has programmed the vtimer, we program a
soft timer to expire in the future to wake up the vcpu thread when
appropriate. Because such as wake up involves a vcpu kick, and the
timer expire function can get called from interrupt context, and the
kick may sleep, we have to schedule the kick in the work function.
The work function currently has a warning that gets raised if it turns
out that the timer shouldn't fire when it's run, which was added because
the idea was that in that case the work should never have been cancelled.
However, it turns out that this whole thing is racy and we can get
spurious warnings. The problem is that we clear the armed flag in the
work function, which may run in parallel with the
kvm_timer_unschedule->timer_disarm() call. This results in a possible
situation where the timer_disarm() call does not call
cancel_work_sync(), which effectively synchronizes the completion of the
work function with running the VCPU. As a result, the VCPU thread
proceeds before the work function completees, causing changes to the
timer state such that kvm_timer_should_fire(vcpu) returns false in the
work function.
All we do in the work function is to kick the VCPU, and an occasional
rare extra kick never harmed anyone. Since the race above is extremely
rare, we don't bother checking if the race happens but simply remove the
check and the clearing of the armed flag from the work function.
Reported-by: Matthias Brugger <mbrugger(a)suse.com>
Reviewed-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
virt/kvm/arm/arch_timer.c | 3 ---
1 file changed, 3 deletions(-)
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -84,9 +84,6 @@ static void kvm_timer_inject_irq_work(st
struct kvm_vcpu *vcpu;
vcpu = container_of(work, struct kvm_vcpu, arch.timer_cpu.expired);
- vcpu->arch.timer_cpu.armed = false;
-
- WARN_ON(!kvm_timer_should_fire(vcpu));
/*
* If the vcpu is blocked we want to wake it up so that it will see
Patches currently in stable-queue which might be from christoffer.dall(a)linaro.org are
queue-4.4/kvm-arm-arm64-fix-occasional-warning-from-the-timer-work-function.patch
This is a note to let you know that I've just added the patch titled
kprobes/x86: Disable preemption in ftrace-based jprobes
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:
kprobes-x86-disable-preemption-in-ftrace-based-jprobes.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Tue, 19 Sep 2017 19:01:40 +0900
Subject: kprobes/x86: Disable preemption in ftrace-based jprobes
From: Masami Hiramatsu <mhiramat(a)kernel.org>
[ Upstream commit 5bb4fc2d8641219732eb2bb654206775a4219aca ]
Disable preemption in ftrace-based jprobe handlers as
described in Documentation/kprobes.txt:
"Probe handlers are run with preemption disabled."
This will fix jprobes behavior when CONFIG_PREEMPT=y.
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Alexei Starovoitov <ast(a)fb.com>
Cc: Alexei Starovoitov <ast(a)kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth(a)linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Paul E . McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/150581530024.32348.9863783558598926771.stgit@devbox
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/ftrace.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -26,7 +26,7 @@
#include "common.h"
static nokprobe_inline
-int __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
+void __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb, unsigned long orig_ip)
{
/*
@@ -41,20 +41,21 @@ int __skip_singlestep(struct kprobe *p,
__this_cpu_write(current_kprobe, NULL);
if (orig_ip)
regs->ip = orig_ip;
- return 1;
}
int skip_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
- if (kprobe_ftrace(p))
- return __skip_singlestep(p, regs, kcb, 0);
- else
- return 0;
+ if (kprobe_ftrace(p)) {
+ __skip_singlestep(p, regs, kcb, 0);
+ preempt_enable_no_resched();
+ return 1;
+ }
+ return 0;
}
NOKPROBE_SYMBOL(skip_singlestep);
-/* Ftrace callback handler for kprobes */
+/* Ftrace callback handler for kprobes -- called under preepmt disabed */
void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *ops, struct pt_regs *regs)
{
@@ -77,13 +78,17 @@ void kprobe_ftrace_handler(unsigned long
/* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
regs->ip = ip + sizeof(kprobe_opcode_t);
+ /* To emulate trap based kprobes, preempt_disable here */
+ preempt_disable();
__this_cpu_write(current_kprobe, p);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
- if (!p->pre_handler || !p->pre_handler(p, regs))
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
__skip_singlestep(p, regs, kcb, orig_ip);
+ preempt_enable_no_resched();
+ }
/*
* If pre_handler returns !0, it sets regs->ip and
- * resets current kprobe.
+ * resets current kprobe, and keep preempt count +1.
*/
}
end:
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.4/kprobes-x86-disable-preemption-in-ftrace-based-jprobes.patch
This is a note to let you know that I've just added the patch titled
EDAC, sb_edac: Fix missing break in switch
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:
edac-sb_edac-fix-missing-break-in-switch.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Mon, 16 Oct 2017 12:40:29 -0500
Subject: EDAC, sb_edac: Fix missing break in switch
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit a8e9b186f153a44690ad0363a56716e7077ad28c ]
Add missing break statement in order to prevent the code from falling
through.
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Cc: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/20171016174029.GA19757@embeddedor.com
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/sb_edac.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1773,6 +1773,7 @@ static int ibridge_mci_bind_devs(struct
break;
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA:
pvt->pci_ta = pdev;
+ break;
case PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_RAS:
pvt->pci_ras = pdev;
break;
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.4/edac-sb_edac-fix-missing-break-in-switch.patch
This is a note to let you know that I've just added the patch titled
drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Andrzej Hajda <a.hajda(a)samsung.com>
Date: Tue, 17 Jan 2017 15:15:20 +0100
Subject: drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
From: Andrzej Hajda <a.hajda(a)samsung.com>
[ Upstream commit 11d8bcef7a0399e1d2519f207fd575fc404306b4 ]
DECON_TV requires STANDALONE_UPDATE after output enabling, otherwise it does
not start. This change is neutral for DECON.
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Signed-off-by: Inki Dae <inki.dae(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -180,6 +180,8 @@ static void decon_commit(struct exynos_d
/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
+
+ decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
}
static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
Patches currently in stable-queue which might be from a.hajda(a)samsung.com are
queue-4.4/drm-exynos-decon5433-set-standalone_update_f-on-output-enablement.patch
This is a note to let you know that I've just added the patch titled
ima: fix hash algorithm initialization
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:
ima-fix-hash-algorithm-initialization.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Boshi Wang <wangboshi(a)huawei.com>
Date: Fri, 20 Oct 2017 16:01:03 +0800
Subject: ima: fix hash algorithm initialization
From: Boshi Wang <wangboshi(a)huawei.com>
[ Upstream commit ebe7c0a7be92bbd34c6ff5b55810546a0ee05bee ]
The hash_setup function always sets the hash_setup_done flag, even
when the hash algorithm is invalid. This prevents the default hash
algorithm defined as CONFIG_IMA_DEFAULT_HASH from being used.
This patch sets hash_setup_done flag only for valid hash algorithms.
Fixes: e7a2ad7eb6f4 "ima: enable support for larger default filedata hash algorithms"
Signed-off-by: Boshi Wang <wangboshi(a)huawei.com>
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_main.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -52,6 +52,8 @@ static int __init hash_setup(char *str)
ima_hash_algo = HASH_ALGO_SHA1;
else if (strncmp(str, "md5", 3) == 0)
ima_hash_algo = HASH_ALGO_MD5;
+ else
+ return 1;
goto out;
}
@@ -61,6 +63,8 @@ static int __init hash_setup(char *str)
break;
}
}
+ if (i == HASH_ALGO__LAST)
+ return 1;
out:
hash_setup_done = 1;
return 1;
Patches currently in stable-queue which might be from wangboshi(a)huawei.com are
queue-4.4/ima-fix-hash-algorithm-initialization.patch
This is a note to let you know that I've just added the patch titled
dmaengine: pl330: fix double lock
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:
dmaengine-pl330-fix-double-lock.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Iago Abal <mail(a)iagoabal.eu>
Date: Wed, 11 Jan 2017 14:00:21 +0100
Subject: dmaengine: pl330: fix double lock
From: Iago Abal <mail(a)iagoabal.eu>
[ Upstream commit 91539eb1fda2d530d3b268eef542c5414e54bf1a ]
The static bug finder EBA (http://www.iagoabal.eu/eba/) reported the
following double-lock bug:
Double lock:
1. spin_lock_irqsave(pch->lock, flags) at pl330_free_chan_resources:2236;
2. call to function `pl330_release_channel' immediately after;
3. call to function `dma_pl330_rqcb' in line 1753;
4. spin_lock_irqsave(pch->lock, flags) at dma_pl330_rqcb:1505.
I have fixed it as suggested by Marek Szyprowski.
First, I have replaced `pch->lock' with `pl330->lock' in functions
`pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids
the double-lock by acquiring a different lock than `dma_pl330_rqcb'.
NOTE that, as a result, `pl330_free_chan_resources' executes
`list_splice_tail_init' on `pch->work_list' under lock `pl330->lock',
whereas in the rest of the code `pch->work_list' is protected by
`pch->lock'. I don't know if this may cause race conditions. Similarly
`pch->cyclic' is written by `pl330_alloc_chan_resources' under
`pl330->lock' but read by `pl330_tx_submit' under `pch->lock'.
Second, I have removed locking from `pl330_request_channel' and
`pl330_release_channel' functions. Function `pl330_request_channel' is
only called from `pl330_alloc_chan_resources', so the lock is already
held. Function `pl330_release_channel' is called from
`pl330_free_chan_resources', which already holds the lock, and from
`pl330_del'. Function `pl330_del' is called in an error path of
`pl330_probe' and at the end of `pl330_remove', but I assume that there
cannot be concurrent accesses to the protected data at those points.
Signed-off-by: Iago Abal <mail(a)iagoabal.eu>
Reviewed-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/pl330.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1657,7 +1657,6 @@ static bool _chan_ns(const struct pl330_
static struct pl330_thread *pl330_request_channel(struct pl330_dmac *pl330)
{
struct pl330_thread *thrd = NULL;
- unsigned long flags;
int chans, i;
if (pl330->state == DYING)
@@ -1665,8 +1664,6 @@ static struct pl330_thread *pl330_reques
chans = pl330->pcfg.num_chan;
- spin_lock_irqsave(&pl330->lock, flags);
-
for (i = 0; i < chans; i++) {
thrd = &pl330->channels[i];
if ((thrd->free) && (!_manager_ns(thrd) ||
@@ -1684,8 +1681,6 @@ static struct pl330_thread *pl330_reques
thrd = NULL;
}
- spin_unlock_irqrestore(&pl330->lock, flags);
-
return thrd;
}
@@ -1703,7 +1698,6 @@ static inline void _free_event(struct pl
static void pl330_release_channel(struct pl330_thread *thrd)
{
struct pl330_dmac *pl330;
- unsigned long flags;
if (!thrd || thrd->free)
return;
@@ -1715,10 +1709,8 @@ static void pl330_release_channel(struct
pl330 = thrd->dmac;
- spin_lock_irqsave(&pl330->lock, flags);
_free_event(thrd, thrd->ev);
thrd->free = true;
- spin_unlock_irqrestore(&pl330->lock, flags);
}
/* Initialize the structure for PL330 configuration, that can be used
@@ -2085,20 +2077,20 @@ static int pl330_alloc_chan_resources(st
struct pl330_dmac *pl330 = pch->dmac;
unsigned long flags;
- spin_lock_irqsave(&pch->lock, flags);
+ spin_lock_irqsave(&pl330->lock, flags);
dma_cookie_init(chan);
pch->cyclic = false;
pch->thread = pl330_request_channel(pl330);
if (!pch->thread) {
- spin_unlock_irqrestore(&pch->lock, flags);
+ spin_unlock_irqrestore(&pl330->lock, flags);
return -ENOMEM;
}
tasklet_init(&pch->task, pl330_tasklet, (unsigned long) pch);
- spin_unlock_irqrestore(&pch->lock, flags);
+ spin_unlock_irqrestore(&pl330->lock, flags);
return 1;
}
@@ -2201,12 +2193,13 @@ static int pl330_pause(struct dma_chan *
static void pl330_free_chan_resources(struct dma_chan *chan)
{
struct dma_pl330_chan *pch = to_pchan(chan);
+ struct pl330_dmac *pl330 = pch->dmac;
unsigned long flags;
tasklet_kill(&pch->task);
pm_runtime_get_sync(pch->dmac->ddma.dev);
- spin_lock_irqsave(&pch->lock, flags);
+ spin_lock_irqsave(&pl330->lock, flags);
pl330_release_channel(pch->thread);
pch->thread = NULL;
@@ -2214,7 +2207,7 @@ static void pl330_free_chan_resources(st
if (pch->cyclic)
list_splice_tail_init(&pch->work_list, &pch->dmac->desc_pool);
- spin_unlock_irqrestore(&pch->lock, flags);
+ spin_unlock_irqrestore(&pl330->lock, flags);
pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
}
Patches currently in stable-queue which might be from mail(a)iagoabal.eu are
queue-4.4/dmaengine-pl330-fix-double-lock.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP1: DMA: Correct the number of logical channels
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-omap1-dma-correct-the-number-of-logical-channels.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 16:43:17 CET 2017
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Tue, 3 Jan 2017 13:22:34 +0200
Subject: ARM: OMAP1: DMA: Correct the number of logical channels
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit 657279778af54f35e54b07b6687918f254a2992c ]
OMAP1510, OMAP5910 and OMAP310 have only 9 logical channels.
OMAP1610, OMAP5912, OMAP1710, OMAP730, and OMAP850 have 16 logical channels
available.
The wired 17 for the lch_count must have been used to cover the 16 + 1
dedicated LCD channel, in reality we can only use 9 or 16 channels.
The d->chan_count is not used by the omap-dma stack, so we can skip the
setup. chan_count was configured to the number of logical channels and not
the actual number of physical channels anyways.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Acked-by: Aaro Koskinen <aaro.koskinen(a)iki.fi>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap1/dma.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -31,7 +31,6 @@
#include "soc.h"
#define OMAP1_DMA_BASE (0xfffed800)
-#define OMAP1_LOGICAL_DMA_CH_COUNT 17
static u32 enable_1510_mode;
@@ -311,8 +310,6 @@ static int __init omap1_system_dma_init(
goto exit_iounmap;
}
- d->lch_count = OMAP1_LOGICAL_DMA_CH_COUNT;
-
/* Valid attributes for omap1 plus processors */
if (cpu_is_omap15xx())
d->dev_caps = ENABLE_1510_MODE;
@@ -329,13 +326,14 @@ static int __init omap1_system_dma_init(
d->dev_caps |= CLEAR_CSR_ON_READ;
d->dev_caps |= IS_WORD_16;
- if (cpu_is_omap15xx())
- d->chan_count = 9;
- else if (cpu_is_omap16xx() || cpu_is_omap7xx()) {
- if (!(d->dev_caps & ENABLE_1510_MODE))
- d->chan_count = 16;
+ /* available logical channels */
+ if (cpu_is_omap15xx()) {
+ d->lch_count = 9;
+ } else {
+ if (d->dev_caps & ENABLE_1510_MODE)
+ d->lch_count = 9;
else
- d->chan_count = 9;
+ d->lch_count = 16;
}
p = dma_plat_info;
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.4/arm-omap1-dma-correct-the-number-of-logical-channels.patch
This is a note to let you know that I've just added the patch titled
USB: serial: usb_debug: add new USB device id
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:
usb-serial-usb_debug-add-new-usb-device-id.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 762ff4678e89a5e3f8b2237533e04d3ef2737e78 Mon Sep 17 00:00:00 2001
From: Lu Baolu <baolu.lu(a)linux.intel.com>
Date: Tue, 28 Nov 2017 12:40:59 +0800
Subject: USB: serial: usb_debug: add new USB device id
From: Lu Baolu <baolu.lu(a)linux.intel.com>
commit 762ff4678e89a5e3f8b2237533e04d3ef2737e78 upstream.
USB vendor id and product id for Linux USB Debug Target is added.
Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/usb_debug.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -34,12 +34,14 @@ static const struct usb_device_id id_tab
};
static const struct usb_device_id dbc_id_table[] = {
+ { USB_DEVICE(0x1d6b, 0x0010) },
{ USB_DEVICE(0x1d6b, 0x0011) },
{ },
};
static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(0x0525, 0x127a) },
+ { USB_DEVICE(0x1d6b, 0x0010) },
{ USB_DEVICE(0x1d6b, 0x0011) },
{ },
};
Patches currently in stable-queue which might be from baolu.lu(a)linux.intel.com are
queue-4.14/usb-serial-usb_debug-add-new-usb-device-id.patch
This is a note to let you know that I've just added the patch titled
USB: serial: option: add Quectel BG96 id
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:
usb-serial-option-add-quectel-bg96-id.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 c654b21ede93845863597de9ad774fd30db5f2ab Mon Sep 17 00:00:00 2001
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
Date: Mon, 20 Nov 2017 19:29:32 +0100
Subject: USB: serial: option: add Quectel BG96 id
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
commit c654b21ede93845863597de9ad774fd30db5f2ab upstream.
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
development board (EVB). The USB id is added to option.c to allow
DIAG,GPS,AT and modem communication with the BG96.
Signed-off-by: Sebastian Sjoholm <ssjoholm(a)mac.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -241,6 +241,7 @@ static void option_instat_callback(struc
/* These Quectel products use Quectel's vendor ID */
#define QUECTEL_PRODUCT_EC21 0x0121
#define QUECTEL_PRODUCT_EC25 0x0125
+#define QUECTEL_PRODUCT_BG96 0x0296
#define CMOTECH_VENDOR_ID 0x16d8
#define CMOTECH_PRODUCT_6001 0x6001
@@ -1185,6 +1186,8 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+ { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
Patches currently in stable-queue which might be from ssjoholm(a)mac.com are
queue-4.14/usb-serial-option-add-quectel-bg96-id.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_early: Only set divisor if valid clk & baud
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:
serial-8250_early-only-set-divisor-if-valid-clk-baud.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 0ff3ab701963a845d52337ded7eebf2d1a14fe00 Mon Sep 17 00:00:00 2001
From: Matt Redfearn <matt.redfearn(a)mips.com>
Date: Wed, 22 Nov 2017 09:57:28 +0000
Subject: serial: 8250_early: Only set divisor if valid clk & baud
From: Matt Redfearn <matt.redfearn(a)mips.com>
commit 0ff3ab701963a845d52337ded7eebf2d1a14fe00 upstream.
If either uartclk or baud are 0, avoid calculating and setting a divisor
based on them since the output will almost certainly be garbage.
This also allows platforms such as the MIPS generic kernel, which has no
way to know a valid BASE_BASE for the board it is actually booted on at
compile time, to set BASE_BAUD to 0 and avoid early_8250 setting a bad
divisor.
This fixes a regression caused by commit 31cb9a8575ca ("earlycon:
initialise baud field of earlycon device structure"), which changed the
behavior of of_setup_earlycon such that it sets a baud rate in the
earlycon structure where previously it was left as 0. All boards
supported by the MIPS generic kernel started outputting garbage from the
boot console due to an incorrect divisor being set.
Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_early.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -125,12 +125,14 @@ static void __init init_port(struct earl
serial8250_early_out(port, UART_FCR, 0); /* no fifo */
serial8250_early_out(port, UART_MCR, 0x3); /* DTR + RTS */
- divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
- c = serial8250_early_in(port, UART_LCR);
- serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB);
- serial8250_early_out(port, UART_DLL, divisor & 0xff);
- serial8250_early_out(port, UART_DLM, (divisor >> 8) & 0xff);
- serial8250_early_out(port, UART_LCR, c & ~UART_LCR_DLAB);
+ if (port->uartclk && device->baud) {
+ divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
+ c = serial8250_early_in(port, UART_LCR);
+ serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB);
+ serial8250_early_out(port, UART_DLL, divisor & 0xff);
+ serial8250_early_out(port, UART_DLM, (divisor >> 8) & 0xff);
+ serial8250_early_out(port, UART_LCR, c & ~UART_LCR_DLAB);
+ }
}
int __init early_serial8250_setup(struct earlycon_device *device,
Patches currently in stable-queue which might be from matt.redfearn(a)mips.com are
queue-4.14/mips-add-custom-serial.h-with-base_baud-override-for-generic-kernel.patch
queue-4.14/serial-8250_early-only-set-divisor-if-valid-clk-baud.patch
This is a note to let you know that I've just added the patch titled
MIPS: Add custom serial.h with BASE_BAUD override for generic kernel
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:
mips-add-custom-serial.h-with-base_baud-override-for-generic-kernel.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 c8ec2041f549e7f2dee0c34d25381be6f7805f99 Mon Sep 17 00:00:00 2001
From: Matt Redfearn <matt.redfearn(a)mips.com>
Date: Tue, 28 Nov 2017 15:22:20 +0000
Subject: MIPS: Add custom serial.h with BASE_BAUD override for generic kernel
From: Matt Redfearn <matt.redfearn(a)mips.com>
commit c8ec2041f549e7f2dee0c34d25381be6f7805f99 upstream.
Add a custom serial.h header for MIPS, allowing platforms to override
the asm-generic version if required.
The generic platform uses this header to set BASE_BAUD to 0. The
generic platform supports multiple boards, which may have different
UART clocks. Also one of the boards supported is the Boston FPGA board,
where the UART clock depends on the loaded FPGA bitfile. As such there
is no way that the generic kernel can set a compile time default
BASE_BAUD.
Commit 31cb9a8575ca ("earlycon: initialise baud field of earlycon device
structure") changed the behavior of of_setup_earlycon such that any baud
rate set in the device tree is now set in the earlycon structure. The
UART driver will then calculate a divisor based on BASE_BAUD and set it.
With MIPS generic kernels this resulted in garbage output due to the
incorrect uart clock rate being used to calculate a divisor. This
commit, combined with "serial: 8250_early: Only set divisor if valid clk
& baud" prevents the earlycon code setting a bad divisor and restores
earlycon output.
Fixes: 31cb9a8575ca ("earlycon: initialise baud field of earlycon device structure")
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/include/asm/Kbuild | 1 -
arch/mips/include/asm/serial.h | 22 ++++++++++++++++++++++
2 files changed, 22 insertions(+), 1 deletion(-)
--- a/arch/mips/include/asm/Kbuild
+++ b/arch/mips/include/asm/Kbuild
@@ -16,7 +16,6 @@ generic-y += qrwlock.h
generic-y += qspinlock.h
generic-y += sections.h
generic-y += segment.h
-generic-y += serial.h
generic-y += trace_clock.h
generic-y += unaligned.h
generic-y += user.h
--- /dev/null
+++ b/arch/mips/include/asm/serial.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2017 MIPS Tech, LLC
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#ifndef __ASM__SERIAL_H
+#define __ASM__SERIAL_H
+
+#ifdef CONFIG_MIPS_GENERIC
+/*
+ * Generic kernels cannot know a correct value for all platforms at
+ * compile time. Set it to 0 to prevent 8250_early using it
+ */
+#define BASE_BAUD 0
+#else
+#include <asm-generic/serial.h>
+#endif
+
+#endif /* __ASM__SERIAL_H */
Patches currently in stable-queue which might be from matt.redfearn(a)mips.com are
queue-4.14/mips-add-custom-serial.h-with-base_baud-override-for-generic-kernel.patch
queue-4.14/serial-8250_early-only-set-divisor-if-valid-clk-baud.patch
This is a note to let you know that I've just added the patch titled
ANDROID: binder: fix transaction leak.
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
android-binder-fix-transaction-leak.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fb2c445277e7b0b4ffe10de8114bad4eccaca948 Mon Sep 17 00:00:00 2001
From: Martijn Coenen <maco(a)android.com>
Date: Mon, 13 Nov 2017 10:06:08 +0100
Subject: ANDROID: binder: fix transaction leak.
From: Martijn Coenen <maco(a)android.com>
commit fb2c445277e7b0b4ffe10de8114bad4eccaca948 upstream.
If a call to put_user() fails, we failed to
properly free a transaction and send a failed
reply (if necessary).
Signed-off-by: Martijn Coenen <maco(a)android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 40 +++++++++++++++++++++++++++++++---------
1 file changed, 31 insertions(+), 9 deletions(-)
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -1948,6 +1948,26 @@ static void binder_send_failed_reply(str
}
/**
+ * binder_cleanup_transaction() - cleans up undelivered transaction
+ * @t: transaction that needs to be cleaned up
+ * @reason: reason the transaction wasn't delivered
+ * @error_code: error to return to caller (if synchronous call)
+ */
+static void binder_cleanup_transaction(struct binder_transaction *t,
+ const char *reason,
+ uint32_t error_code)
+{
+ if (t->buffer->target_node && !(t->flags & TF_ONE_WAY)) {
+ binder_send_failed_reply(t, error_code);
+ } else {
+ binder_debug(BINDER_DEBUG_DEAD_TRANSACTION,
+ "undelivered transaction %d, %s\n",
+ t->debug_id, reason);
+ binder_free_transaction(t);
+ }
+}
+
+/**
* binder_validate_object() - checks for a valid metadata object in a buffer.
* @buffer: binder_buffer that we're parsing.
* @offset: offset in the buffer at which to validate an object.
@@ -4015,12 +4035,20 @@ retry:
if (put_user(cmd, (uint32_t __user *)ptr)) {
if (t_from)
binder_thread_dec_tmpref(t_from);
+
+ binder_cleanup_transaction(t, "put_user failed",
+ BR_FAILED_REPLY);
+
return -EFAULT;
}
ptr += sizeof(uint32_t);
if (copy_to_user(ptr, &tr, sizeof(tr))) {
if (t_from)
binder_thread_dec_tmpref(t_from);
+
+ binder_cleanup_transaction(t, "copy_to_user failed",
+ BR_FAILED_REPLY);
+
return -EFAULT;
}
ptr += sizeof(tr);
@@ -4090,15 +4118,9 @@ static void binder_release_work(struct b
struct binder_transaction *t;
t = container_of(w, struct binder_transaction, work);
- if (t->buffer->target_node &&
- !(t->flags & TF_ONE_WAY)) {
- binder_send_failed_reply(t, BR_DEAD_REPLY);
- } else {
- binder_debug(BINDER_DEBUG_DEAD_TRANSACTION,
- "undelivered transaction %d\n",
- t->debug_id);
- binder_free_transaction(t);
- }
+
+ binder_cleanup_transaction(t, "process died.",
+ BR_DEAD_REPLY);
} break;
case BINDER_WORK_RETURN_ERROR: {
struct binder_error *e = container_of(
Patches currently in stable-queue which might be from maco(a)android.com are
queue-4.14/android-binder-fix-transaction-leak.patch
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 1ac7c8a78be85f84b019d3d2742d1a9f07255cc5 Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Wed, 29 Nov 2017 15:24:22 -0700
Subject: [PATCH] usbip: fix usbip attach to find a port that matches the
requested speed
usbip attach fails to find a free port when the device on the first port
is a USB_SPEED_SUPER device and non-super speed device is being attached.
It keeps checking the first port and returns without a match getting stuck
in a loop.
Fix it check to find the first port with matching speed.
Reported-by: Juan Zea <juan.zea(a)qindel.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c b/tools/usb/usbip/libsrc/vhci_driver.c
index 5727dfb15a83..8a1cd1616de4 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -329,9 +329,17 @@ int usbip_vhci_refresh_device_list(void)
int usbip_vhci_get_free_port(uint32_t speed)
{
for (int i = 0; i < vhci_driver->nports; i++) {
- if (speed == USB_SPEED_SUPER &&
- vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
- continue;
+
+ switch (speed) {
+ case USB_SPEED_SUPER:
+ if (vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
+ continue;
+ break;
+ default:
+ if (vhci_driver->idev[i].hub != HUB_SPEED_HIGH)
+ continue;
+ break;
+ }
if (vhci_driver->idev[i].status == VDEV_ST_NULL)
return vhci_driver->idev[i].port;
This is a note to let you know that I've just added the patch titled
s390/runtime instrumentation: simplify task exit handling
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:
s390-runtime-instrumentation-simplify-task-exit-handling.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 8d9047f8b967ce6181fd824ae922978e1b055cc0 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Date: Mon, 11 Sep 2017 11:24:22 +0200
Subject: s390/runtime instrumentation: simplify task exit handling
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 upstream.
Free data structures required for runtime instrumentation from
arch_release_task_struct(). This allows to simplify the code a bit,
and also makes the semantics a bit easier: arch_release_task_struct()
is never called from the task that is being removed.
In addition this allows to get rid of exit_thread() in a later patch.
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/include/asm/runtime_instr.h | 4 +++-
arch/s390/kernel/process.c | 3 +--
arch/s390/kernel/runtime_instr.c | 30 +++++++++++++++---------------
3 files changed, 19 insertions(+), 18 deletions(-)
--- a/arch/s390/include/asm/runtime_instr.h
+++ b/arch/s390/include/asm/runtime_instr.h
@@ -85,6 +85,8 @@ static inline void restore_ri_cb(struct
load_runtime_instr_cb(&runtime_instr_empty_cb);
}
-void exit_thread_runtime_instr(void);
+struct task_struct;
+
+void runtime_instr_release(struct task_struct *tsk);
#endif /* _RUNTIME_INSTR_H */
--- a/arch/s390/kernel/process.c
+++ b/arch/s390/kernel/process.c
@@ -70,8 +70,6 @@ extern void kernel_thread_starter(void);
*/
void exit_thread(struct task_struct *tsk)
{
- if (tsk == current)
- exit_thread_runtime_instr();
}
void flush_thread(void)
@@ -84,6 +82,7 @@ void release_thread(struct task_struct *
void arch_release_task_struct(struct task_struct *tsk)
{
+ runtime_instr_release(tsk);
}
int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
--- a/arch/s390/kernel/runtime_instr.c
+++ b/arch/s390/kernel/runtime_instr.c
@@ -18,11 +18,24 @@
/* empty control block to disable RI by loading it */
struct runtime_instr_cb runtime_instr_empty_cb;
+void runtime_instr_release(struct task_struct *tsk)
+{
+ kfree(tsk->thread.ri_cb);
+}
+
static void disable_runtime_instr(void)
{
- struct pt_regs *regs = task_pt_regs(current);
+ struct task_struct *task = current;
+ struct pt_regs *regs;
+ if (!task->thread.ri_cb)
+ return;
+ regs = task_pt_regs(task);
+ preempt_disable();
load_runtime_instr_cb(&runtime_instr_empty_cb);
+ kfree(task->thread.ri_cb);
+ task->thread.ri_cb = NULL;
+ preempt_enable();
/*
* Make sure the RI bit is deleted from the PSW. If the user did not
@@ -43,19 +56,6 @@ static void init_runtime_instr_cb(struct
cb->valid = 1;
}
-void exit_thread_runtime_instr(void)
-{
- struct task_struct *task = current;
-
- preempt_disable();
- if (!task->thread.ri_cb)
- return;
- disable_runtime_instr();
- kfree(task->thread.ri_cb);
- task->thread.ri_cb = NULL;
- preempt_enable();
-}
-
SYSCALL_DEFINE1(s390_runtime_instr, int, command)
{
struct runtime_instr_cb *cb;
@@ -64,7 +64,7 @@ SYSCALL_DEFINE1(s390_runtime_instr, int,
return -EOPNOTSUPP;
if (command == S390_RUNTIME_INSTR_STOP) {
- exit_thread_runtime_instr();
+ disable_runtime_instr();
return 0;
}
Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are
queue-4.9/s390-runtime-instrumentation-simplify-task-exit-handling.patch
This is a note to let you know that I've just added the patch titled
s390/runtime instrumentation: simplify task exit handling
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:
s390-runtime-instrumentation-simplify-task-exit-handling.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 8d9047f8b967ce6181fd824ae922978e1b055cc0 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Date: Mon, 11 Sep 2017 11:24:22 +0200
Subject: s390/runtime instrumentation: simplify task exit handling
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 upstream.
Free data structures required for runtime instrumentation from
arch_release_task_struct(). This allows to simplify the code a bit,
and also makes the semantics a bit easier: arch_release_task_struct()
is never called from the task that is being removed.
In addition this allows to get rid of exit_thread() in a later patch.
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/include/asm/runtime_instr.h | 4 +++-
arch/s390/kernel/process.c | 2 +-
arch/s390/kernel/runtime_instr.c | 30 +++++++++++++++---------------
3 files changed, 19 insertions(+), 17 deletions(-)
--- a/arch/s390/include/asm/runtime_instr.h
+++ b/arch/s390/include/asm/runtime_instr.h
@@ -85,6 +85,8 @@ static inline void restore_ri_cb(struct
load_runtime_instr_cb(&runtime_instr_empty_cb);
}
-void exit_thread_runtime_instr(void);
+struct task_struct;
+
+void runtime_instr_release(struct task_struct *tsk);
#endif /* _RUNTIME_INSTR_H */
--- a/arch/s390/kernel/process.c
+++ b/arch/s390/kernel/process.c
@@ -72,7 +72,6 @@ extern void kernel_thread_starter(void);
*/
void exit_thread(void)
{
- exit_thread_runtime_instr();
}
void flush_thread(void)
@@ -87,6 +86,7 @@ void arch_release_task_struct(struct tas
{
/* Free either the floating-point or the vector register save area */
kfree(tsk->thread.fpu.regs);
+ runtime_instr_release(tsk);
}
int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
--- a/arch/s390/kernel/runtime_instr.c
+++ b/arch/s390/kernel/runtime_instr.c
@@ -18,11 +18,24 @@
/* empty control block to disable RI by loading it */
struct runtime_instr_cb runtime_instr_empty_cb;
+void runtime_instr_release(struct task_struct *tsk)
+{
+ kfree(tsk->thread.ri_cb);
+}
+
static void disable_runtime_instr(void)
{
- struct pt_regs *regs = task_pt_regs(current);
+ struct task_struct *task = current;
+ struct pt_regs *regs;
+ if (!task->thread.ri_cb)
+ return;
+ regs = task_pt_regs(task);
+ preempt_disable();
load_runtime_instr_cb(&runtime_instr_empty_cb);
+ kfree(task->thread.ri_cb);
+ task->thread.ri_cb = NULL;
+ preempt_enable();
/*
* Make sure the RI bit is deleted from the PSW. If the user did not
@@ -43,19 +56,6 @@ static void init_runtime_instr_cb(struct
cb->valid = 1;
}
-void exit_thread_runtime_instr(void)
-{
- struct task_struct *task = current;
-
- preempt_disable();
- if (!task->thread.ri_cb)
- return;
- disable_runtime_instr();
- kfree(task->thread.ri_cb);
- task->thread.ri_cb = NULL;
- preempt_enable();
-}
-
SYSCALL_DEFINE1(s390_runtime_instr, int, command)
{
struct runtime_instr_cb *cb;
@@ -64,7 +64,7 @@ SYSCALL_DEFINE1(s390_runtime_instr, int,
return -EOPNOTSUPP;
if (command == S390_RUNTIME_INSTR_STOP) {
- exit_thread_runtime_instr();
+ disable_runtime_instr();
return 0;
}
Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are
queue-4.4/s390-runtime-instrumentation-simplify-task-exit-handling.patch
This is a note to let you know that I've just added the patch titled
usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
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-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.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 e43a12f1793ae1fe006e26fe9327a8840a92233c Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Tue, 14 Nov 2017 01:31:15 -0500
Subject: usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit e43a12f1793ae1fe006e26fe9327a8840a92233c upstream.
KY-688 USB 3.1 Type-C Hub internally uses a Genesys Logic hub to connect
to Realtek r8153.
Similar to commit ("7496cfe5431f2 usb: quirks: Add no-lpm quirk for Moshi
USB to Ethernet Adapter"), no-lpm can make r8153 ethernet work.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -151,6 +151,9 @@ static const struct usb_device_id usb_qu
/* appletouch */
{ USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Genesys Logic hub, internally used by KY-688 USB 3.1 Type-C Hub */
+ { USB_DEVICE(0x05e3, 0x0612), .driver_info = USB_QUIRK_NO_LPM },
+
/* Genesys Logic hub, internally used by Moshi USB to Ethernet Adapter */
{ USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.9/usb-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.patch
This is a note to let you know that I've just added the patch titled
uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
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:
uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.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 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Tue, 14 Nov 2017 19:27:22 +0100
Subject: uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
From: Hans de Goede <hdegoede(a)redhat.com>
commit 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 upstream.
We've been adding this as a quirk on a per device basis hoping that
newer disk enclosures would do better, but that has not happened,
so simply apply this quirk to all Seagate devices.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas-detect.h | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -111,6 +111,10 @@ static int uas_use_uas_driver(struct usb
}
}
+ /* All Seagate disk enclosures have broken ATA pass-through support */
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
+ flags |= US_FL_NO_ATA_1X;
+
usb_stor_adjust_quirks(udev, &flags);
if (flags & US_FL_IGNORE_UAS) {
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Amazon PCI serial device ID
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:
serial-8250_pci-add-amazon-pci-serial-device-id.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 3bfd1300abfe3adb18e84a89d97a0e82a22124bb Mon Sep 17 00:00:00 2001
From: Matt Wilson <msw(a)amazon.com>
Date: Mon, 13 Nov 2017 11:31:31 -0800
Subject: serial: 8250_pci: Add Amazon PCI serial device ID
From: Matt Wilson <msw(a)amazon.com>
commit 3bfd1300abfe3adb18e84a89d97a0e82a22124bb upstream.
This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).
[1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.…
Signed-off-by: Matt Wilson <msw(a)amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5568,6 +5568,9 @@ static struct pci_device_id serial_pci_t
{ PCI_DEVICE(0x1601, 0x0800), .driver_data = pbn_b0_4_1250000 },
{ PCI_DEVICE(0x1601, 0xa801), .driver_data = pbn_b0_4_1250000 },
+ /* Amazon PCI serial device */
+ { PCI_DEVICE(0x1d0f, 0x8250), .driver_data = pbn_b0_1_115200 },
+
/*
* These entries match devices with class COMMUNICATION_SERIAL,
* COMMUNICATION_MODEM or COMMUNICATION_MULTISERIAL
Patches currently in stable-queue which might be from msw(a)amazon.com are
queue-4.9/serial-8250_pci-add-amazon-pci-serial-device-id.patch
This is a note to let you know that I've just added the patch titled
usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
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:
usb-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.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 e43a12f1793ae1fe006e26fe9327a8840a92233c Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Tue, 14 Nov 2017 01:31:15 -0500
Subject: usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit e43a12f1793ae1fe006e26fe9327a8840a92233c upstream.
KY-688 USB 3.1 Type-C Hub internally uses a Genesys Logic hub to connect
to Realtek r8153.
Similar to commit ("7496cfe5431f2 usb: quirks: Add no-lpm quirk for Moshi
USB to Ethernet Adapter"), no-lpm can make r8153 ethernet work.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -151,6 +151,9 @@ static const struct usb_device_id usb_qu
/* appletouch */
{ USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Genesys Logic hub, internally used by KY-688 USB 3.1 Type-C Hub */
+ { USB_DEVICE(0x05e3, 0x0612), .driver_info = USB_QUIRK_NO_LPM },
+
/* Genesys Logic hub, internally used by Moshi USB to Ethernet Adapter */
{ USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.4/usb-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.patch
This is a note to let you know that I've just added the patch titled
uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
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:
uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.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 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Tue, 14 Nov 2017 19:27:22 +0100
Subject: uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
From: Hans de Goede <hdegoede(a)redhat.com>
commit 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 upstream.
We've been adding this as a quirk on a per device basis hoping that
newer disk enclosures would do better, but that has not happened,
so simply apply this quirk to all Seagate devices.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas-detect.h | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -111,6 +111,10 @@ static int uas_use_uas_driver(struct usb
}
}
+ /* All Seagate disk enclosures have broken ATA pass-through support */
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
+ flags |= US_FL_NO_ATA_1X;
+
usb_stor_adjust_quirks(udev, &flags);
if (flags & US_FL_IGNORE_UAS) {
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.4/uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Amazon PCI serial device ID
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:
serial-8250_pci-add-amazon-pci-serial-device-id.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 3bfd1300abfe3adb18e84a89d97a0e82a22124bb Mon Sep 17 00:00:00 2001
From: Matt Wilson <msw(a)amazon.com>
Date: Mon, 13 Nov 2017 11:31:31 -0800
Subject: serial: 8250_pci: Add Amazon PCI serial device ID
From: Matt Wilson <msw(a)amazon.com>
commit 3bfd1300abfe3adb18e84a89d97a0e82a22124bb upstream.
This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).
[1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.…
Signed-off-by: Matt Wilson <msw(a)amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5797,6 +5797,9 @@ static struct pci_device_id serial_pci_t
{ PCI_DEVICE(0x1601, 0x0800), .driver_data = pbn_b0_4_1250000 },
{ PCI_DEVICE(0x1601, 0xa801), .driver_data = pbn_b0_4_1250000 },
+ /* Amazon PCI serial device */
+ { PCI_DEVICE(0x1d0f, 0x8250), .driver_data = pbn_b0_1_115200 },
+
/*
* These entries match devices with class COMMUNICATION_SERIAL,
* COMMUNICATION_MODEM or COMMUNICATION_MULTISERIAL
Patches currently in stable-queue which might be from msw(a)amazon.com are
queue-4.4/serial-8250_pci-add-amazon-pci-serial-device-id.patch
This is a note to let you know that I've just added the patch titled
usbip: fix usbip attach to find a port that matches the requested speed
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-usbip-attach-to-find-a-port-that-matches-the-requested-speed.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1ac7c8a78be85f84b019d3d2742d1a9f07255cc5 Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Wed, 29 Nov 2017 15:24:22 -0700
Subject: usbip: fix usbip attach to find a port that matches the requested speed
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit 1ac7c8a78be85f84b019d3d2742d1a9f07255cc5 upstream.
usbip attach fails to find a free port when the device on the first port
is a USB_SPEED_SUPER device and non-super speed device is being attached.
It keeps checking the first port and returns without a match getting stuck
in a loop.
Fix it check to find the first port with matching speed.
Reported-by: Juan Zea <juan.zea(a)qindel.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/libsrc/vhci_driver.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -329,9 +329,17 @@ err:
int usbip_vhci_get_free_port(uint32_t speed)
{
for (int i = 0; i < vhci_driver->nports; i++) {
- if (speed == USB_SPEED_SUPER &&
- vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
- continue;
+
+ switch (speed) {
+ case USB_SPEED_SUPER:
+ if (vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
+ continue;
+ break;
+ default:
+ if (vhci_driver->idev[i].hub != HUB_SPEED_HIGH)
+ continue;
+ break;
+ }
if (vhci_driver->idev[i].status == VDEV_ST_NULL)
return vhci_driver->idev[i].port;
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.14/usbip-fix-usbip-attach-to-find-a-port-that-matches-the-requested-speed.patch
queue-4.14/usbip-fix-usb-device-hang-due-to-wrong-enabling-of-scatter-gather.patch
This is a note to let you know that I've just added the patch titled
usbip: Fix USB device hang due to wrong enabling of scatter-gather
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:
usbip-fix-usb-device-hang-due-to-wrong-enabling-of-scatter-gather.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 770b2edece42fa55bbe7d4cbe53347a07b8968d4 Mon Sep 17 00:00:00 2001
From: Yuyang Du <yuyang.du(a)intel.com>
Date: Thu, 30 Nov 2017 10:22:40 +0800
Subject: usbip: Fix USB device hang due to wrong enabling of scatter-gather
From: Yuyang Du <yuyang.du(a)intel.com>
commit 770b2edece42fa55bbe7d4cbe53347a07b8968d4 upstream.
The previous USB3 SuperSpeed enabling patches mistakenly enabled
URB scatter-gather chaining, which is actually not supported by
the VHCI HCD. This patch fixes that.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197867
Fixes: 03cd00d538a6feb ("usbip: vhci-hcd: Set the vhci structure up to work")
Reported-by: Juan Zea <juan.zea(a)qindel.com>
Signed-off-by: Yuyang Du <yuyang.du(a)intel.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/vhci_hcd.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1112,7 +1112,6 @@ static int hcd_name_to_id(const char *na
static int vhci_setup(struct usb_hcd *hcd)
{
struct vhci *vhci = *((void **)dev_get_platdata(hcd->self.controller));
- hcd->self.sg_tablesize = ~0;
if (usb_hcd_is_primary_hcd(hcd)) {
vhci->vhci_hcd_hs = hcd_to_vhci_hcd(hcd);
vhci->vhci_hcd_hs->vhci = vhci;
Patches currently in stable-queue which might be from yuyang.du(a)intel.com are
queue-4.14/usbip-fix-usb-device-hang-due-to-wrong-enabling-of-scatter-gather.patch
This is a note to let you know that I've just added the patch titled
usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
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:
usb-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.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 e43a12f1793ae1fe006e26fe9327a8840a92233c Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Tue, 14 Nov 2017 01:31:15 -0500
Subject: usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit e43a12f1793ae1fe006e26fe9327a8840a92233c upstream.
KY-688 USB 3.1 Type-C Hub internally uses a Genesys Logic hub to connect
to Realtek r8153.
Similar to commit ("7496cfe5431f2 usb: quirks: Add no-lpm quirk for Moshi
USB to Ethernet Adapter"), no-lpm can make r8153 ethernet work.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -151,6 +151,9 @@ static const struct usb_device_id usb_qu
/* appletouch */
{ USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Genesys Logic hub, internally used by KY-688 USB 3.1 Type-C Hub */
+ { USB_DEVICE(0x05e3, 0x0612), .driver_info = USB_QUIRK_NO_LPM },
+
/* Genesys Logic hub, internally used by Moshi USB to Ethernet Adapter */
{ USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.14/usb-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.patch
This is a note to let you know that I've just added the patch titled
uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
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:
uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.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 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Tue, 14 Nov 2017 19:27:22 +0100
Subject: uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
From: Hans de Goede <hdegoede(a)redhat.com>
commit 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 upstream.
We've been adding this as a quirk on a per device basis hoping that
newer disk enclosures would do better, but that has not happened,
so simply apply this quirk to all Seagate devices.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas-detect.h | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -112,6 +112,10 @@ static int uas_use_uas_driver(struct usb
}
}
+ /* All Seagate disk enclosures have broken ATA pass-through support */
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
+ flags |= US_FL_NO_ATA_1X;
+
usb_stor_adjust_quirks(udev, &flags);
if (flags & US_FL_IGNORE_UAS) {
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Amazon PCI serial device ID
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:
serial-8250_pci-add-amazon-pci-serial-device-id.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 3bfd1300abfe3adb18e84a89d97a0e82a22124bb Mon Sep 17 00:00:00 2001
From: Matt Wilson <msw(a)amazon.com>
Date: Mon, 13 Nov 2017 11:31:31 -0800
Subject: serial: 8250_pci: Add Amazon PCI serial device ID
From: Matt Wilson <msw(a)amazon.com>
commit 3bfd1300abfe3adb18e84a89d97a0e82a22124bb upstream.
This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).
[1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.…
Signed-off-by: Matt Wilson <msw(a)amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5137,6 +5137,9 @@ static const struct pci_device_id serial
{ PCI_DEVICE(0x1601, 0x0800), .driver_data = pbn_b0_4_1250000 },
{ PCI_DEVICE(0x1601, 0xa801), .driver_data = pbn_b0_4_1250000 },
+ /* Amazon PCI serial device */
+ { PCI_DEVICE(0x1d0f, 0x8250), .driver_data = pbn_b0_1_115200 },
+
/*
* These entries match devices with class COMMUNICATION_SERIAL,
* COMMUNICATION_MODEM or COMMUNICATION_MULTISERIAL
Patches currently in stable-queue which might be from msw(a)amazon.com are
queue-4.14/serial-8250_pci-add-amazon-pci-serial-device-id.patch
This is a note to let you know that I've just added the patch titled
usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e43a12f1793ae1fe006e26fe9327a8840a92233c Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Tue, 14 Nov 2017 01:31:15 -0500
Subject: usb: quirks: Add no-lpm quirk for KY-688 USB 3.1 Type-C Hub
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit e43a12f1793ae1fe006e26fe9327a8840a92233c upstream.
KY-688 USB 3.1 Type-C Hub internally uses a Genesys Logic hub to connect
to Realtek r8153.
Similar to commit ("7496cfe5431f2 usb: quirks: Add no-lpm quirk for Moshi
USB to Ethernet Adapter"), no-lpm can make r8153 ethernet work.
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -144,6 +144,9 @@ static const struct usb_device_id usb_qu
/* appletouch */
{ USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Genesys Logic hub, internally used by KY-688 USB 3.1 Type-C Hub */
+ { USB_DEVICE(0x05e3, 0x0612), .driver_info = USB_QUIRK_NO_LPM },
+
/* Genesys Logic hub, internally used by Moshi USB to Ethernet Adapter */
{ USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-3.18/usb-quirks-add-no-lpm-quirk-for-ky-688-usb-3.1-type-c-hub.patch
This is a note to let you know that I've just added the patch titled
uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Tue, 14 Nov 2017 19:27:22 +0100
Subject: uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices
From: Hans de Goede <hdegoede(a)redhat.com>
commit 7fee72d5e8f1e7b8d8212e28291b1a0243ecf2f1 upstream.
We've been adding this as a quirk on a per device basis hoping that
newer disk enclosures would do better, but that has not happened,
so simply apply this quirk to all Seagate devices.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/uas-detect.h | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -88,6 +88,10 @@ static int uas_use_uas_driver(struct usb
}
}
+ /* All Seagate disk enclosures have broken ATA pass-through support */
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
+ flags |= US_FL_NO_ATA_1X;
+
usb_stor_adjust_quirks(udev, &flags);
if (flags & US_FL_IGNORE_UAS) {
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-3.18/uas-always-apply-us_fl_no_ata_1x-quirk-to-seagate-devices.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Amazon PCI serial device ID
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
serial-8250_pci-add-amazon-pci-serial-device-id.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3bfd1300abfe3adb18e84a89d97a0e82a22124bb Mon Sep 17 00:00:00 2001
From: Matt Wilson <msw(a)amazon.com>
Date: Mon, 13 Nov 2017 11:31:31 -0800
Subject: serial: 8250_pci: Add Amazon PCI serial device ID
From: Matt Wilson <msw(a)amazon.com>
commit 3bfd1300abfe3adb18e84a89d97a0e82a22124bb upstream.
This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).
[1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.…
Signed-off-by: Matt Wilson <msw(a)amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5483,6 +5483,9 @@ static struct pci_device_id serial_pci_t
{ PCI_DEVICE(0x1601, 0x0800), .driver_data = pbn_b0_4_1250000 },
{ PCI_DEVICE(0x1601, 0xa801), .driver_data = pbn_b0_4_1250000 },
+ /* Amazon PCI serial device */
+ { PCI_DEVICE(0x1d0f, 0x8250), .driver_data = pbn_b0_1_115200 },
+
/*
* These entries match devices with class COMMUNICATION_SERIAL,
* COMMUNICATION_MODEM or COMMUNICATION_MULTISERIAL
Patches currently in stable-queue which might be from msw(a)amazon.com are
queue-3.18/serial-8250_pci-add-amazon-pci-serial-device-id.patch
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 1ac7c8a78be85f84b019d3d2742d1a9f07255cc5 Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Wed, 29 Nov 2017 15:24:22 -0700
Subject: [PATCH] usbip: fix usbip attach to find a port that matches the
requested speed
usbip attach fails to find a free port when the device on the first port
is a USB_SPEED_SUPER device and non-super speed device is being attached.
It keeps checking the first port and returns without a match getting stuck
in a loop.
Fix it check to find the first port with matching speed.
Reported-by: Juan Zea <juan.zea(a)qindel.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c b/tools/usb/usbip/libsrc/vhci_driver.c
index 5727dfb15a83..8a1cd1616de4 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -329,9 +329,17 @@ int usbip_vhci_refresh_device_list(void)
int usbip_vhci_get_free_port(uint32_t speed)
{
for (int i = 0; i < vhci_driver->nports; i++) {
- if (speed == USB_SPEED_SUPER &&
- vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
- continue;
+
+ switch (speed) {
+ case USB_SPEED_SUPER:
+ if (vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
+ continue;
+ break;
+ default:
+ if (vhci_driver->idev[i].hub != HUB_SPEED_HIGH)
+ continue;
+ break;
+ }
if (vhci_driver->idev[i].status == VDEV_ST_NULL)
return vhci_driver->idev[i].port;
This is a note to let you know that I've just added the patch titled
s390/runtime instrumentation: simplify task exit handling
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:
s390-runtime-instrumentation-simplify-task-exit-handling.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 8d9047f8b967ce6181fd824ae922978e1b055cc0 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Date: Mon, 11 Sep 2017 11:24:22 +0200
Subject: s390/runtime instrumentation: simplify task exit handling
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
commit 8d9047f8b967ce6181fd824ae922978e1b055cc0 upstream.
Free data structures required for runtime instrumentation from
arch_release_task_struct(). This allows to simplify the code a bit,
and also makes the semantics a bit easier: arch_release_task_struct()
is never called from the task that is being removed.
In addition this allows to get rid of exit_thread() in a later patch.
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/include/asm/runtime_instr.h | 4 +++-
arch/s390/kernel/process.c | 5 ++---
arch/s390/kernel/runtime_instr.c | 30 +++++++++++++++---------------
3 files changed, 20 insertions(+), 19 deletions(-)
--- a/arch/s390/include/asm/runtime_instr.h
+++ b/arch/s390/include/asm/runtime_instr.h
@@ -86,6 +86,8 @@ static inline void restore_ri_cb(struct
load_runtime_instr_cb(&runtime_instr_empty_cb);
}
-void exit_thread_runtime_instr(void);
+struct task_struct;
+
+void runtime_instr_release(struct task_struct *tsk);
#endif /* _RUNTIME_INSTR_H */
--- a/arch/s390/kernel/process.c
+++ b/arch/s390/kernel/process.c
@@ -49,10 +49,8 @@ extern void kernel_thread_starter(void);
*/
void exit_thread(struct task_struct *tsk)
{
- if (tsk == current) {
- exit_thread_runtime_instr();
+ if (tsk == current)
exit_thread_gs();
- }
}
void flush_thread(void)
@@ -65,6 +63,7 @@ void release_thread(struct task_struct *
void arch_release_task_struct(struct task_struct *tsk)
{
+ runtime_instr_release(tsk);
}
int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
--- a/arch/s390/kernel/runtime_instr.c
+++ b/arch/s390/kernel/runtime_instr.c
@@ -21,11 +21,24 @@
/* empty control block to disable RI by loading it */
struct runtime_instr_cb runtime_instr_empty_cb;
+void runtime_instr_release(struct task_struct *tsk)
+{
+ kfree(tsk->thread.ri_cb);
+}
+
static void disable_runtime_instr(void)
{
- struct pt_regs *regs = task_pt_regs(current);
+ struct task_struct *task = current;
+ struct pt_regs *regs;
+ if (!task->thread.ri_cb)
+ return;
+ regs = task_pt_regs(task);
+ preempt_disable();
load_runtime_instr_cb(&runtime_instr_empty_cb);
+ kfree(task->thread.ri_cb);
+ task->thread.ri_cb = NULL;
+ preempt_enable();
/*
* Make sure the RI bit is deleted from the PSW. If the user did not
@@ -46,19 +59,6 @@ static void init_runtime_instr_cb(struct
cb->valid = 1;
}
-void exit_thread_runtime_instr(void)
-{
- struct task_struct *task = current;
-
- preempt_disable();
- if (!task->thread.ri_cb)
- return;
- disable_runtime_instr();
- kfree(task->thread.ri_cb);
- task->thread.ri_cb = NULL;
- preempt_enable();
-}
-
SYSCALL_DEFINE1(s390_runtime_instr, int, command)
{
struct runtime_instr_cb *cb;
@@ -67,7 +67,7 @@ SYSCALL_DEFINE1(s390_runtime_instr, int,
return -EOPNOTSUPP;
if (command == S390_RUNTIME_INSTR_STOP) {
- exit_thread_runtime_instr();
+ disable_runtime_instr();
return 0;
}
Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are
queue-4.14/s390-runtime-instrumentation-simplify-task-exit-handling.patch
Hi Felipe,
Hi John,
Am 30.10.2017 um 18:08 schrieb Douglas Anderson:
> On rk3288-veyron devices on Chrome OS it was found that plugging in an
> Arduino-based USB device could cause the system to lockup, especially
> if the CPU Frequency was at one of the slower operating points (like
> 100 MHz / 200 MHz).
>
> Upon tracing, I found that the following was happening:
> * The USB device (full speed) was connected to a high speed hub and
> then to the rk3288. Thus, we were dealing with split transactions,
> which is all handled in software on dwc2.
> * Userspace was initiating a BULK IN transfer
> * When we sent the SSPLIT (to start the split transaction), we got an
> ACK. Good. Then we issued the CSPLIT.
> * When we sent the CSPLIT, we got back a NAK. We immediately (from
> the interrupt handler) started to retry and sent another SSPLIT.
> * The device kept NAKing our CSPLIT, so we kept ping-ponging between
> sending a SSPLIT and a CSPLIT, each time sending from the interrupt
> handler.
> * The handling of the interrupts was (because of the low CPU speed and
> the inefficiency of the dwc2 interrupt handler) was actually taking
> _longer_ than it took the other side to send the ACK/NAK. Thus we
> were _always_ in the USB interrupt routine.
> * The fact that USB interrupts were always going off was preventing
> other things from happening in the system. This included preventing
> the system from being able to transition to a higher CPU frequency.
>
> As I understand it, there is no requirement to retry super quickly
> after a NAK, we just have to retry sometime in the future. Thus one
> solution to the above is to just add a delay between getting a NAK and
> retrying the transmission. If this delay is sufficiently long to get
> out of the interrupt routine then the rest of the system will be able
> to make forward progress. Even a 25 us delay would probably be
> enough, but we'll be extra conservative and try to delay 1 ms (the
> exact amount depends on HZ and the accuracy of the jiffy and how close
> the current jiffy is to ticking, but could be as much as 20 ms or as
> little as 1 ms).
>
> Presumably adding a delay like this could impact the USB throughput,
> so we only add the delay with repeated NAKs.
>
> NOTE: Upon further testing of a pl2303 serial adapter, I found that
> this fix may help with problems there. Specifically I found that the
> pl2303 serial adapters tend to respond with a NAK when they have
> nothing to say and thus we end with this same sequence.
>
> Signed-off-by: Douglas Anderson <dianders(a)chromium.org>
> Cc: stable(a)vger.kernel.org
> Reviewed-by: Julius Werner <jwerner(a)chromium.org>
> Tested-by: Stefan Wahren <stefan.wahren(a)i2se.com>
> ---
>
> Changes in v3:
> - Add tested-by for Stefan Wahren
> - Sent to Felipe Balbi as candiate to land this.
> - Add Cc for stable (it's always been broken so go as far is as easy)
>
> Changes in v2:
> - Address http://crosreview.com/737520 feedback
>
does it need a resend?
When debugging e.g. the SCSI timeout handler it is important that
requests that have not yet been started or that already have
completed are also reported through debugfs.
Fixes: commit 2720bab50258 ("blk-mq-debugfs: Show busy requests")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Ming Lei <ming.lei(a)redhat.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Cc: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: stable(a)vger.kernel.org
---
block/blk-mq-debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
index f7db73f1698e..886b37163f17 100644
--- a/block/blk-mq-debugfs.c
+++ b/block/blk-mq-debugfs.c
@@ -409,7 +409,7 @@ static void hctx_show_busy_rq(struct request *rq, void *data, bool reserved)
const struct show_busy_params *params = data;
if (blk_mq_map_queue(rq->q, rq->mq_ctx->cpu) == params->hctx &&
- test_bit(REQ_ATOM_STARTED, &rq->atomic_flags))
+ list_empty(&rq->queuelist))
__blk_mq_debugfs_rq_show(params->m,
list_entry_rq(&rq->queuelist));
}
--
2.15.0
The patch titled
Subject: autofs: fix careless error in recent commit
has been added to the -mm tree. Its filename is
autofs-fix-careless-error-in-recent-commit.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/autofs-fix-careless-error-in-recen…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-careless-error-in-recen…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: NeilBrown <neilb(a)suse.com>
Subject: autofs: fix careless error in recent commit
ecc0c469f277 ("autofs: don't fail mount for transient error") was meant to
replace an 'if' with a 'switch', but instead added the 'switch' leaving
the case in place.
Link: http://lkml.kernel.org/r/87zi6wstmw.fsf@notabene.neil.brown.name
Fixes: ecc0c469f277 ("autofs: don't fail mount for transient error")
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: NeilBrown <neilb(a)suse.com>
Cc: Ian Kent <raven(a)themaw.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/autofs4/waitq.c | 1 -
1 file changed, 1 deletion(-)
diff -puN fs/autofs4/waitq.c~autofs-fix-careless-error-in-recent-commit fs/autofs4/waitq.c
--- a/fs/autofs4/waitq.c~autofs-fix-careless-error-in-recent-commit
+++ a/fs/autofs4/waitq.c
@@ -170,7 +170,6 @@ static void autofs4_notify_daemon(struct
mutex_unlock(&sbi->wq_mutex);
- if (autofs4_write(sbi, pipe, &pkt, pktsz))
switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) {
case 0:
break;
_
Patches currently in -mm which might be from neilb(a)suse.com are
autofs-fix-careless-error-in-recent-commit.patch
Hi, all
Is there someone knows if exists one utilis dedicated to UFS device, rather than SCSI utils?
I have tried sg3-utils, but it is not convenient for the embedded ARM-based system.
And also it doesn't support several UFS special command.
If we don't have this kind of tool for UFS, is it necessary for us to develop a ufs-utils?
I need your every expert's inputs and suggestions.
Thanks in advance.
//Bean Huo
The patch titled
Subject: string.h: workaround for increased stack usage
has been added to the -mm tree. Its filename is
stringh-work-around-for-increased-stack-usage.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/stringh-work-around-for-increased-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/stringh-work-around-for-increased-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Arnd Bergmann <arnd(a)arndb.de>
Subject: string.h: workaround for increased stack usage
The hardened strlen() function causes rather large stack usage in at least
one file in the kernel, in particular when CONFIG_KASAN is enabled:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=]
Analyzing this problem led to the discovery that gcc fails to merge the
stack slots for the i2c_board_info[] structures after we strlcpy() into
them, due to the 'noreturn' attribute on the source string length check.
I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8,
since it is relatively easy to work around, and it gets triggered rarely.
An earlier workaround I did added an empty inline assembly statement
before the call to fortify_panic(), which works surprisingly well, but is
really ugly and unintuitive.
This is a new approach to the same problem, this time addressing it by not
calling the 'extern __real_strnlen()' function for string constants where
__builtin_strlen() is a compile-time constant and therefore known to be
safe. We do this by checking if the last character in the string is a
compile-time constant '\0'. If it is, we can assume that strlen() of the
string is also constant. As a side-effect, this should also improve the
object code output for any other call of strlen() on a string constant.
Link: http://lkml.kernel.org/r/20171205215143.3085755-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Link: https://patchwork.kernel.org/patch/9980413/
Link: https://patchwork.kernel.org/patch/9974047/
Fixes: 6974f0c4555 ("include/linux/string.h: add the option of fortified string.h functions")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Daniel Micay <danielmicay(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Martin Wilck <mwilck(a)suse.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/string.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN include/linux/string.h~stringh-work-around-for-increased-stack-usage include/linux/string.h
--- a/include/linux/string.h~stringh-work-around-for-increased-stack-usage
+++ a/include/linux/string.h
@@ -259,7 +259,8 @@ __FORTIFY_INLINE __kernel_size_t strlen(
{
__kernel_size_t ret;
size_t p_size = __builtin_object_size(p, 0);
- if (p_size == (size_t)-1)
+ if (p_size == (size_t)-1 ||
+ (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
return __builtin_strlen(p);
ret = strnlen(p, p_size);
if (p_size <= ret)
_
Patches currently in -mm which might be from arnd(a)arndb.de are
stringh-work-around-for-increased-stack-usage.patch
The hardened strlen() function causes rather large stack usage in at
least one file in the kernel, in particular when CONFIG_KASAN is enabled:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=]
Analyzing this problem led to the discovery that gcc fails to merge the
stack slots for the i2c_board_info[] structures after we strlcpy() into
them, due to the 'noreturn' attribute on the source string length check.
I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8,
since it is relatively easy to work around, and it gets triggered rarely.
An earlier workaround I did added an empty inline assembly statement
before the call to fortify_panic(), which works surprisingly well,
but is really ugly and unintuitive.
This is a new approach to the same problem, this time addressing it by
not calling the 'extern __real_strnlen()' function for string constants
where __builtin_strlen() is a compile-time constant and therefore known
to be safe. We do this by checking if the last character in the string
is a compile-time constant '\0'. If it is, we can assume that
strlen() of the string is also constant. As a side-effect, this should
also improve the object code output for any other call of strlen()
on a string constant.
Cc: stable(a)vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Link: https://patchwork.kernel.org/patch/9980413/
Link: https://patchwork.kernel.org/patch/9974047/
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
v3: don't use an asm barrier but use a constant string change.
Aside from two other patches for drivers/media that I sent last week,
this should fix all stack frames above 2KB, once all three are merged,
I'll send the patch to re-enable the warning.
---
include/linux/string.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/string.h b/include/linux/string.h
index 410ecf17de3c..e5cc3f27f6e0 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -259,7 +259,8 @@ __FORTIFY_INLINE __kernel_size_t strlen(const char *p)
{
__kernel_size_t ret;
size_t p_size = __builtin_object_size(p, 0);
- if (p_size == (size_t)-1)
+ if (p_size == (size_t)-1 ||
+ (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
return __builtin_strlen(p);
ret = strnlen(p, p_size);
if (p_size <= ret)
--
2.9.0
From: Daniel Jurgens <danielj(a)mellanox.com>
Per the infiniband spec an SMI MAD can have any PKey. Checking the pkey
on SMI MADs is not necessary, and it seems that some older adapters
using the mthca driver don't follow the convention of using the default
PKey, resulting in false denials, or errors querying the PKey cache.
SMI MAD security is still enforced, only agents allowed to manage the
subnet are able to receive or send SMI MADs.
Reported-by: Chris Blake <chrisrblake93(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # v4.12
Fixes: 47a2b338fe63 ("IB/core: Enforce security on management datagrams")
Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com>
Reviewed-by: Parav Pandit <parav(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
---
drivers/infiniband/core/security.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/security.c b/drivers/infiniband/core/security.c
index a337386652b0..feafdb961c48 100644
--- a/drivers/infiniband/core/security.c
+++ b/drivers/infiniband/core/security.c
@@ -739,8 +739,11 @@ int ib_mad_enforce_security(struct ib_mad_agent_private *map, u16 pkey_index)
if (!rdma_protocol_ib(map->agent.device, map->agent.port_num))
return 0;
- if (map->agent.qp->qp_type == IB_QPT_SMI && !map->agent.smp_allowed)
- return -EACCES;
+ if (map->agent.qp->qp_type == IB_QPT_SMI) {
+ if (!map->agent.smp_allowed)
+ return -EACCES;
+ return 0;
+ }
return ib_security_pkey_access(map->agent.device,
map->agent.port_num,
--
2.15.1
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e492080e640c2d1235ddf3441cae634cfffef7e1 Mon Sep 17 00:00:00 2001
From: Jaewon Kim <jaewon31.kim(a)samsung.com>
Date: Wed, 15 Nov 2017 17:39:07 -0800
Subject: [PATCH] mm/page_ext.c: check if page_ext is not prepared
online_page_ext() and page_ext_init() allocate page_ext for each
section, but they do not allocate if the first PFN is !pfn_present(pfn)
or !pfn_valid(pfn). Then section->page_ext remains as NULL.
lookup_page_ext checks NULL only if CONFIG_DEBUG_VM is enabled. For a
valid PFN, __set_page_owner will try to get page_ext through
lookup_page_ext. Without CONFIG_DEBUG_VM lookup_page_ext will misuse
NULL pointer as value 0. This incurrs invalid address access.
This is the panic example when PFN 0x100000 is not valid but PFN
0x13FC00 is being used for page_ext. section->page_ext is NULL,
get_entry returned invalid page_ext address as 0x1DFA000 for a PFN
0x13FC00.
To avoid this panic, CONFIG_DEBUG_VM should be removed so that page_ext
will be checked at all times.
Unable to handle kernel paging request at virtual address 01dfa014
------------[ cut here ]------------
Kernel BUG at ffffff80082371e0 [verbose debug info unavailable]
Internal error: Oops: 96000045 [#1] PREEMPT SMP
Modules linked in:
PC is at __set_page_owner+0x48/0x78
LR is at __set_page_owner+0x44/0x78
__set_page_owner+0x48/0x78
get_page_from_freelist+0x880/0x8e8
__alloc_pages_nodemask+0x14c/0xc48
__do_page_cache_readahead+0xdc/0x264
filemap_fault+0x2ac/0x550
ext4_filemap_fault+0x3c/0x58
__do_fault+0x80/0x120
handle_mm_fault+0x704/0xbb0
do_page_fault+0x2e8/0x394
do_mem_abort+0x88/0x124
Pre-4.7 kernels also need commit f86e4271978b ("mm: check the return
value of lookup_page_ext for all call sites").
Link: http://lkml.kernel.org/r/20171107094131.14621-1-jaewon31.kim@samsung.com
Fixes: eefa864b701d ("mm/page_ext: resurrect struct page extending code for debugging")
Signed-off-by: Jaewon Kim <jaewon31.kim(a)samsung.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Joonsoo Kim <js1304(a)gmail.com>
Cc: <stable(a)vger.kernel.org> [depends on f86e427197, see above]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
diff --git a/mm/page_ext.c b/mm/page_ext.c
index 4f0367d472c4..2c16216c29b6 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -125,7 +125,6 @@ struct page_ext *lookup_page_ext(struct page *page)
struct page_ext *base;
base = NODE_DATA(page_to_nid(page))->node_page_ext;
-#if defined(CONFIG_DEBUG_VM)
/*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -134,7 +133,6 @@ struct page_ext *lookup_page_ext(struct page *page)
*/
if (unlikely(!base))
return NULL;
-#endif
index = pfn - round_down(node_start_pfn(page_to_nid(page)),
MAX_ORDER_NR_PAGES);
return get_entry(base, index);
@@ -199,7 +197,6 @@ struct page_ext *lookup_page_ext(struct page *page)
{
unsigned long pfn = page_to_pfn(page);
struct mem_section *section = __pfn_to_section(pfn);
-#if defined(CONFIG_DEBUG_VM)
/*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -208,7 +205,6 @@ struct page_ext *lookup_page_ext(struct page *page)
*/
if (!section->page_ext)
return NULL;
-#endif
return get_entry(section->page_ext, pfn);
}
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers to deal
with pages that have been improperly dirtied") and it didn't do any error
handling then. This function might very well fail in ENOMEM situation, yet
it's not handled, this could lead to inconsistent state. So let's handle the
failure by setting the mapping error bit.
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Cc: stable(a)vger.kernel.org
---
fs/btrfs/inode.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 993061f83067..7a5a46fefdb4 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2098,8 +2098,15 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, 0, &cached_state,
- 0);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end, 0,
+ &cached_state, 0);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
btrfs_delalloc_release_extents(BTRFS_I(inode), PAGE_SIZE);
--
2.7.4
On Mon, Nov 27, 2017 at 09:35:02AM -0800, Michael Lyle wrote:
> On Mon, Nov 27, 2017 at 9:01 AM, Jens Axboe <axboe(a)kernel.dk> wrote:
>
> > On 11/27/2017 09:45 AM, Eddie Chapman wrote:
> > > On 27/11/17 16:06, gregkh(a)linuxfoundation.org wrote:
> > >>
> > >> This is a note to let you know that I've just added the patch titled
> > >>
> > >> bcache: only permit to recovery read error when cache device is
> > clean
> >
>
>
> > > Hi Greg,
> > >
> > > This patch is an important fix for a possible data corruption issue, but
> > > it also introduces a bug that can produce read errors under certain
> > > circumstances. The issue introduced by this patch is not as severe as
> > > the issue it fixes, but can lead to e.g. upper layer fs remounting read
> > > only. In my environment upper layer handled it badly and indirectly
> > > resulted in data loss (not directly bcache's fault of course).
> > >
> > > Michael Lyle CC'd the stable list with a follow up fix for the issue
> > > introduced by this patch, on 24th Nov, subject "bcache: recover data
> > > from backing when data is clean".
> > >
> > > However, the followup fix is not in Linus' tree yet, only in Michael's.
> > > I guess that means you can't pick it up yet. Never-the-less I felt it
> > > important to point this out here.
> >
> > It's commit e393aa2446150536929140739f09c6ecbcbea7f0 in my tree and will
> > go upstream shortly - but yes, probably should not add this one, before
> > both can be pulled in.
>
>
> Thanks everyone for the quick reply on this. I agree.
Ok, I've dropped this patch from all of the stable queues for now.
thanks,
greg k-h
This is a note to let you know that I've just added the patch titled
mm, oom_reaper: gather each vma to prevent leaking TLB entry
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-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry.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 687cb0884a714ff484d038e9190edc874edcf146 Mon Sep 17 00:00:00 2001
From: Wang Nan <wangnan0(a)huawei.com>
Date: Wed, 29 Nov 2017 16:09:58 -0800
Subject: mm, oom_reaper: gather each vma to prevent leaking TLB entry
From: Wang Nan <wangnan0(a)huawei.com>
commit 687cb0884a714ff484d038e9190edc874edcf146 upstream.
tlb_gather_mmu(&tlb, mm, 0, -1) means gathering the whole virtual memory
space. In this case, tlb->fullmm is true. Some archs like arm64
doesn't flush TLB when tlb->fullmm is true:
commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1").
Which causes leaking of tlb entries.
Will clarifies his patch:
"Basically, we tag each address space with an ASID (PCID on x86) which
is resident in the TLB. This means we can elide TLB invalidation when
pulling down a full mm because we won't ever assign that ASID to
another mm without doing TLB invalidation elsewhere (which actually
just nukes the whole TLB).
I think that means that we could potentially not fault on a kernel
uaccess, because we could hit in the TLB"
There could be a window between complete_signal() sending IPI to other
cores and all threads sharing this mm are really kicked off from cores.
In this window, the oom reaper may calls tlb_flush_mmu_tlbonly() to
flush TLB then frees pages. However, due to the above problem, the TLB
entries are not really flushed on arm64. Other threads are possible to
access these pages through TLB entries. Moreover, a copy_to_user() can
also write to these pages without generating page fault, causes
use-after-free bugs.
This patch gathers each vma instead of gathering full vm space. In this
case tlb->fullmm is not true. The behavior of oom reaper become similar
to munmapping before do_exit, which should be safe for all archs.
Link: http://lkml.kernel.org/r/20171107095453.179940-1-wangnan0@huawei.com
Fixes: aac453635549 ("mm, oom: introduce oom reaper")
Signed-off-by: Wang Nan <wangnan0(a)huawei.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Acked-by: David Rientjes <rientjes(a)google.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: Bob Liu <liubo95(a)huawei.com>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Roman Gushchin <guro(a)fb.com>
Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru>
Cc: Andrea Arcangeli <aarcange(a)redhat.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>
[backported to 4.9 stable tree]
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/oom_kill.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -524,7 +524,6 @@ static bool __oom_reap_task_mm(struct ta
*/
set_bit(MMF_UNSTABLE, &mm->flags);
- tlb_gather_mmu(&tlb, mm, 0, -1);
for (vma = mm->mmap ; vma; vma = vma->vm_next) {
if (is_vm_hugetlb_page(vma))
continue;
@@ -546,11 +545,13 @@ static bool __oom_reap_task_mm(struct ta
* we do not want to block exit_mmap by keeping mm ref
* count elevated without a good reason.
*/
- if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED))
+ if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED)) {
+ tlb_gather_mmu(&tlb, mm, vma->vm_start, vma->vm_end);
unmap_page_range(&tlb, vma, vma->vm_start, vma->vm_end,
&details);
+ tlb_finish_mmu(&tlb, vma->vm_start, vma->vm_end);
+ }
}
- tlb_finish_mmu(&tlb, 0, -1);
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
K(get_mm_counter(mm, MM_ANONPAGES)),
Patches currently in stable-queue which might be from wangnan0(a)huawei.com are
queue-4.9/mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Use unsigned ring indices in amdgpu_queue_mgr_map
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:
drm-amdgpu-use-unsigned-ring-indices-in-amdgpu_queue_mgr_map.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 fa7c7939b4bf112cd06ba166b739244077898990 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer(a)amd.com>
Date: Wed, 22 Nov 2017 15:55:21 +0100
Subject: drm/amdgpu: Use unsigned ring indices in amdgpu_queue_mgr_map
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Michel Dänzer <michel.daenzer(a)amd.com>
commit fa7c7939b4bf112cd06ba166b739244077898990 upstream.
This matches the corresponding UAPI fields. Treating the ring index as
signed could result in accessing random unrelated memory if the MSB was
set.
Fixes: effd924d2f3b ("drm/amdgpu: untie user ring ids from kernel ring ids v6")
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -697,7 +697,7 @@ int amdgpu_queue_mgr_fini(struct amdgpu_
struct amdgpu_queue_mgr *mgr);
int amdgpu_queue_mgr_map(struct amdgpu_device *adev,
struct amdgpu_queue_mgr *mgr,
- int hw_ip, int instance, int ring,
+ u32 hw_ip, u32 instance, u32 ring,
struct amdgpu_ring **out_ring);
/*
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c
@@ -63,7 +63,7 @@ static int amdgpu_update_cached_map(stru
static int amdgpu_identity_map(struct amdgpu_device *adev,
struct amdgpu_queue_mapper *mapper,
- int ring,
+ u32 ring,
struct amdgpu_ring **out_ring)
{
switch (mapper->hw_ip) {
@@ -121,7 +121,7 @@ static enum amdgpu_ring_type amdgpu_hw_i
static int amdgpu_lru_map(struct amdgpu_device *adev,
struct amdgpu_queue_mapper *mapper,
- int user_ring,
+ u32 user_ring,
struct amdgpu_ring **out_ring)
{
int r, i, j;
@@ -208,7 +208,7 @@ int amdgpu_queue_mgr_fini(struct amdgpu_
*/
int amdgpu_queue_mgr_map(struct amdgpu_device *adev,
struct amdgpu_queue_mgr *mgr,
- int hw_ip, int instance, int ring,
+ u32 hw_ip, u32 instance, u32 ring,
struct amdgpu_ring **out_ring)
{
int r, ip_num_rings;
Patches currently in stable-queue which might be from michel.daenzer(a)amd.com are
queue-4.14/drm-amdgpu-use-unsigned-ring-indices-in-amdgpu_queue_mgr_map.patch
This is a note to let you know that I've just added the patch titled
usbip: tools: Install all headers needed for libusbip development
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-tools-install-all-headers-needed-for-libusbip-development.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Ben Hutchings <ben(a)decadent.org.uk>
Date: Sun, 1 Oct 2017 02:18:37 +0100
Subject: usbip: tools: Install all headers needed for libusbip development
From: Ben Hutchings <ben(a)decadent.org.uk>
[ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
usbip_host_driver.h now depends on several additional headers, which
need to be installed along with it.
Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver ...")
Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with ...")
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/tools/usb/usbip/Makefile.am
+++ b/tools/usb/usbip/Makefile.am
@@ -1,6 +1,7 @@
SUBDIRS := libsrc src
includedir = @includedir@/usbip
include_HEADERS := $(addprefix libsrc/, \
- usbip_common.h vhci_driver.h usbip_host_driver.h)
+ usbip_common.h vhci_driver.h usbip_host_driver.h \
+ list.h sysfs_utils.h usbip_host_common.h)
dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8)
Patches currently in stable-queue which might be from ben(a)decadent.org.uk are
queue-3.18/usbip-tools-install-all-headers-needed-for-libusbip-development.patch
This is a note to let you know that I've just added the patch titled
tipc: fix cleanup at module unload
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tipc-fix-cleanup-at-module-unload.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com>
Date: Tue, 24 Jan 2017 13:00:48 +0100
Subject: tipc: fix cleanup at module unload
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com>
[ Upstream commit 35e22e49a5d6a741ebe7f2dd280b2052c3003ef7 ]
In tipc_server_stop(), we iterate over the connections with limiting
factor as server's idr_in_use. We ignore the fact that this variable
is decremented in tipc_close_conn(), leading to premature exit.
In this commit, we iterate until the we have no connections left.
Acked-by: Ying Xue <ying.xue(a)windriver.com>
Acked-by: Jon Maloy <jon.maloy(a)ericsson.com>
Tested-by: John Thompson <thompa.atl(a)gmail.com>
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.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>
---
net/tipc/server.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/net/tipc/server.c
+++ b/net/tipc/server.c
@@ -579,14 +579,12 @@ int tipc_server_start(struct tipc_server
void tipc_server_stop(struct tipc_server *s)
{
struct tipc_conn *con;
- int total = 0;
int id;
spin_lock_bh(&s->idr_lock);
- for (id = 0; total < s->idr_in_use; id++) {
+ for (id = 0; s->idr_in_use; id++) {
con = idr_find(&s->conn_idr, id);
if (con) {
- total++;
spin_unlock_bh(&s->idr_lock);
tipc_close_conn(con);
spin_lock_bh(&s->idr_lock);
Patches currently in stable-queue which might be from parthasarathy.bhuvaragan(a)ericsson.com are
queue-3.18/tipc-fix-cleanup-at-module-unload.patch
This is a note to let you know that I've just added the patch titled
vti6: fix device register to report IFLA_INFO_KIND
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
vti6-fix-device-register-to-report-ifla_info_kind.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: David Forster <dforster(a)brocade.com>
Date: Fri, 6 Jan 2017 10:27:59 +0000
Subject: vti6: fix device register to report IFLA_INFO_KIND
From: David Forster <dforster(a)brocade.com>
[ Upstream commit 93e246f783e6bd1bc64fdfbfe68b18161f69b28e ]
vti6 interface is registered before the rtnl_link_ops block
is attached. As a result the resulting RTM_NEWLINK is missing
IFLA_INFO_KIND. Re-order attachment of rtnl_link_ops block to fix.
Signed-off-by: Dave Forster <dforster(a)brocade.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>
---
net/ipv6/ip6_vti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -172,12 +172,12 @@ static int vti6_tnl_create2(struct net_d
struct vti6_net *ip6n = net_generic(net, vti6_net_id);
int err;
+ dev->rtnl_link_ops = &vti6_link_ops;
err = register_netdevice(dev);
if (err < 0)
goto out;
strcpy(t->parms.name, dev->name);
- dev->rtnl_link_ops = &vti6_link_ops;
dev_hold(dev);
vti6_tnl_link(ip6n, t);
Patches currently in stable-queue which might be from dforster(a)brocade.com are
queue-3.18/vti6-fix-device-register-to-report-ifla_info_kind.patch
This is a note to let you know that I've just added the patch titled
sysrq : fix Show Regs call trace on ARM
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sysrq-fix-show-regs-call-trace-on-arm.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Jibin Xu <jibin.xu(a)windriver.com>
Date: Sun, 10 Sep 2017 20:11:42 -0700
Subject: sysrq : fix Show Regs call trace on ARM
From: Jibin Xu <jibin.xu(a)windriver.com>
[ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]
When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 >/proc/sys/kernel/sysrq
echo p >/proc/sysrq-trigger
kernel will print call trace as below:
sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[<ffffff8008088e80>] dump_backtrace+0x0/0x1d0
[<ffffff8008089074>] show_stack+0x24/0x30
[<ffffff8008447970>] dump_stack+0x90/0xb0
[<ffffff8008463950>] check_preemption_disabled+0x100/0x108
[<ffffff8008463998>] __this_cpu_preempt_check+0x18/0x20
[<ffffff80084c9194>] sysrq_handle_showregs+0x1c/0x40
[<ffffff80084c9c7c>] __handle_sysrq+0x12c/0x1a0
[<ffffff80084ca140>] write_sysrq_trigger+0x60/0x70
[<ffffff8008251e00>] proc_reg_write+0x90/0xd0
[<ffffff80081f1788>] __vfs_write+0x48/0x90
[<ffffff80081f241c>] vfs_write+0xa4/0x190
[<ffffff80081f3354>] SyS_write+0x54/0xb0
[<ffffff80080833f0>] el0_svc_naked+0x24/0x28
This can be seen on a common board like an r-pi3.
This happens because when echo p >/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.
Signed-off-by: Jibin Xu <jibin.xu(a)windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/sysrq.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -237,8 +237,10 @@ static void sysrq_handle_showallcpus(int
* architecture has no support for it:
*/
if (!trigger_all_cpu_backtrace()) {
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+ if (in_irq())
+ regs = get_irq_regs();
if (regs) {
printk(KERN_INFO "CPU%d:\n", smp_processor_id());
show_regs(regs);
@@ -257,7 +259,10 @@ static struct sysrq_key_op sysrq_showall
static void sysrq_handle_showregs(int key)
{
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+
+ if (in_irq())
+ regs = get_irq_regs();
if (regs)
show_regs(regs);
perf_event_print_debug();
Patches currently in stable-queue which might be from jibin.xu(a)windriver.com are
queue-3.18/sysrq-fix-show-regs-call-trace-on-arm.patch
This is a note to let you know that I've just added the patch titled
spi: sh-msiof: Fix DMA transfer size check
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
spi-sh-msiof-fix-dma-transfer-size-check.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Date: Thu, 2 Nov 2017 10:32:36 +0100
Subject: spi: sh-msiof: Fix DMA transfer size check
From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
[ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ]
DMA supports 32-bit words only,
even if BITLEN1 of SITMDR2 register is 16bit.
Fixes: b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support")
Signed-off-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Dirk Behme <dirk.behme(a)de.bosch.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-sh-msiof.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -818,7 +818,7 @@ static int sh_msiof_transfer_one(struct
break;
copy32 = copy_bswap32;
} else if (bits <= 16) {
- if (l & 1)
+ if (l & 3)
break;
copy32 = copy_wswap32;
} else {
Patches currently in stable-queue which might be from hiromitsu.yamasaki.ym(a)renesas.com are
queue-3.18/spi-sh-msiof-fix-dma-transfer-size-check.patch
This is a note to let you know that I've just added the patch titled
perf test attr: Fix ignored test case result
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-test-attr-fix-ignored-test-case-result.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
Date: Wed, 13 Sep 2017 10:12:09 +0200
Subject: perf test attr: Fix ignored test case result
From: Thomas Richter <tmricht(a)linux.vnet.ibm.com>
[ Upstream commit 22905582f6dd4bbd0c370fe5732c607452010c04 ]
Command perf test -v 16 (Setup struct perf_event_attr test) always
reports success even if the test case fails. It works correctly if you
also specify -F (for don't fork).
root@s35lp76 perf]# ./perf test -v 16
15: Setup struct perf_event_attr :
--- start ---
running './tests/attr/test-record-no-delay'
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB /tmp/tmp4E1h7R/perf.data
(1 samples) ]
expected task=0, got 1
expected precise_ip=0, got 3
expected wakeup_events=1, got 0
FAILED './tests/attr/test-record-no-delay' - match failure
test child finished with 0
---- end ----
Setup struct perf_event_attr: Ok
The reason for the wrong error reporting is the return value of the
system() library call. It is called in run_dir() file tests/attr.c and
returns the exit status, in above case 0xff00.
This value is given as parameter to the exit() function which can only
handle values 0-0xff.
The child process terminates with exit value of 0 and the parent does
not detect any error.
This patch corrects the error reporting and prints the correct test
result.
Signed-off-by: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa(a)kernel.org>
Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Cc: Hendrik Brueckner <brueckner(a)linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Cc: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com>
LPU-Reference: 20170913081209.39570-2-tmricht(a)linux.vnet.ibm.com
Link: http://lkml.kernel.org/n/tip-rdube6rfcjsr1nzue72c7lqn@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/tests/attr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -150,7 +150,7 @@ static int run_dir(const char *d, const
snprintf(cmd, 3*PATH_MAX, PYTHON " %s/attr.py -d %s/attr/ -p %s %.*s",
d, d, perf, vcnt, v);
- return system(cmd);
+ return system(cmd) ? TEST_FAIL : TEST_OK;
}
int test__attr(void)
Patches currently in stable-queue which might be from tmricht(a)linux.vnet.ibm.com are
queue-3.18/perf-test-attr-fix-ignored-test-case-result.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Lukas Wunner <lukas(a)wunner.de>
Date: Sat, 28 Oct 2017 11:35:49 +0200
Subject: serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
From: Lukas Wunner <lukas(a)wunner.de>
[ Upstream commit 3236a965486ba0c6043cf2c7b51943d8b382ae29 ]
This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND
and SER_RS485_RTS_AFTER_SEND have the same value. If they do, it means
the user has passed in invalid data with the TIOCSRS485 ioctl()
since RTS must have a different polarity when sending and when not
sending. In this case, rs485 mode is not enabled (the RS485_URA bit
is not set in the RS485 Enable Register) and this is supposed to be
signaled back to the user by clearing the SER_RS485_ENABLED bit in
struct serial_rs485 ... except a missing tilde character is preventing
that from happening.
Fixes: 28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART")
Cc: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Cc: "Ji-Ze Hong (Peter Hong)" <hpeter(a)gmail.com>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_fintek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/8250/8250_fintek.c
+++ b/drivers/tty/serial/8250/8250_fintek.c
@@ -118,7 +118,7 @@ static int fintek_8250_rs4850_config(str
if ((!!(rs485->flags & SER_RS485_RTS_ON_SEND)) ==
(!!(rs485->flags & SER_RS485_RTS_AFTER_SEND)))
- rs485->flags &= SER_RS485_ENABLED;
+ rs485->flags &= ~SER_RS485_ENABLED;
else
config |= RS485_URA;
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-3.18/serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch
This is a note to let you know that I've just added the patch titled
NFSv4: Fix client recovery when server reboots multiple times
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Fri, 13 Jan 2017 13:31:32 -0500
Subject: NFSv4: Fix client recovery when server reboots multiple times
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit c6180a6237174f481dc856ed6e890d8196b6f0fb ]
If the server reboots multiple times, the client should rely on the
server to tell it that it cannot reclaim state as per section 9.6.3.4
in RFC7530 and section 8.4.2.1 in RFC5661.
Currently, the client is being to conservative, and is assuming that
if the server reboots while state recovery is in progress, then it must
ignore state that was not recovered before the reboot.
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4state.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -1650,7 +1650,6 @@ static int nfs4_recovery_handle_error(st
break;
case -NFS4ERR_STALE_CLIENTID:
set_bit(NFS4CLNT_LEASE_EXPIRED, &clp->cl_state);
- nfs4_state_clear_reclaim_reboot(clp);
nfs4_state_start_reclaim_reboot(clp);
break;
case -NFS4ERR_EXPIRED:
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-3.18/nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch
queue-3.18/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
This is a note to let you know that I've just added the patch titled
net: sctp: fix array overrun read on sctp_timer_tbl
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 20 Jan 2017 13:01:57 +0000
Subject: net: sctp: fix array overrun read on sctp_timer_tbl
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 0e73fc9a56f22f2eec4d2b2910c649f7af67b74d ]
The comparison on the timeout can lead to an array overrun
read on sctp_timer_tbl because of an off-by-one error. Fix
this by using < instead of <= and also compare to the array
size rather than SCTP_EVENT_TIMEOUT_MAX.
Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
Signed-off-by: Colin Ian King <colin.king(a)canonical.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>
---
net/sctp/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sctp/debug.c
+++ b/net/sctp/debug.c
@@ -166,7 +166,7 @@ static const char *const sctp_timer_tbl[
/* Lookup timer debug name. */
const char *sctp_tname(const sctp_subtype_t id)
{
- if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
+ if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
return sctp_timer_tbl[id.timeout];
return "unknown_timer";
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-3.18/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
This is a note to let you know that I've just added the patch titled
nfs: Don't take a reference on fl->fl_file for LOCK operation
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Benjamin Coddington <bcodding(a)redhat.com>
Date: Thu, 5 Jan 2017 10:20:16 -0500
Subject: nfs: Don't take a reference on fl->fl_file for LOCK operation
From: Benjamin Coddington <bcodding(a)redhat.com>
[ Upstream commit 4b09ec4b14a168bf2c687e1f598140c3c11e9222 ]
I have reports of a crash that look like __fput() was called twice for
a NFSv4.0 file. It seems possible that the state manager could try to
reclaim a lock and take a reference on the fl->fl_file at the same time the
file is being released if, during the close(), a signal interrupts the wait
for outstanding IO while removing locks which then skips the removal
of that lock.
Since 83bfff23e9ed ("nfs4: have do_vfs_lock take an inode pointer") has
removed the need to traverse fl->fl_file->f_inode in nfs4_lock_done(),
taking that reference is no longer necessary.
Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com>
Reviewed-by: Jeff Layton <jlayton(a)redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4proc.c | 3 ---
1 file changed, 3 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -38,7 +38,6 @@
#include <linux/mm.h>
#include <linux/delay.h>
#include <linux/errno.h>
-#include <linux/file.h>
#include <linux/string.h>
#include <linux/ratelimit.h>
#include <linux/printk.h>
@@ -5544,7 +5543,6 @@ static struct nfs4_lockdata *nfs4_alloc_
p->server = server;
atomic_inc(&lsp->ls_count);
p->ctx = get_nfs_open_context(ctx);
- get_file(fl->fl_file);
memcpy(&p->fl, fl, sizeof(p->fl));
return p;
out_free_seqid:
@@ -5634,7 +5632,6 @@ static void nfs4_lock_release(void *call
nfs_free_seqid(data->arg.lock_seqid);
nfs4_put_lock_state(data->lsp);
put_nfs_open_context(data->ctx);
- fput(data->fl.fl_file);
kfree(data);
dprintk("%s: done!\n", __func__);
}
Patches currently in stable-queue which might be from bcodding(a)redhat.com are
queue-3.18/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch
This is a note to let you know that I've just added the patch titled
net/appletalk: Fix kernel memory disclosure
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-appletalk-fix-kernel-memory-disclosure.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net>
Date: Mon, 9 Jan 2017 20:57:48 +0700
Subject: net/appletalk: Fix kernel memory disclosure
From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net>
[ Upstream commit ce7e40c432ba84da104438f6799d460a4cad41bc ]
ipddp_route structs contain alignment padding so kernel heap memory
is leaked when they are copied to user space in
ipddp_ioctl(SIOCFINDIPDDPRT). Change kmalloc() to kzalloc() to clear
that memory.
Signed-off-by: Vlad Tsyrklevich <vlad(a)tsyrklevich.net>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/appletalk/ipddp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/appletalk/ipddp.c
+++ b/drivers/net/appletalk/ipddp.c
@@ -191,7 +191,7 @@ static netdev_tx_t ipddp_xmit(struct sk_
*/
static int ipddp_create(struct ipddp_route *new_rt)
{
- struct ipddp_route *rt = kmalloc(sizeof(*rt), GFP_KERNEL);
+ struct ipddp_route *rt = kzalloc(sizeof(*rt), GFP_KERNEL);
if (rt == NULL)
return -ENOMEM;
Patches currently in stable-queue which might be from vlad(a)tsyrklevich.net are
queue-3.18/net-appletalk-fix-kernel-memory-disclosure.patch
This is a note to let you know that I've just added the patch titled
net: fec: fix multicast filtering hardware setup
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-fec-fix-multicast-filtering-hardware-setup.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Rui Sousa <rui.sousa(a)nxp.com>
Date: Mon, 13 Feb 2017 10:01:25 +0800
Subject: net: fec: fix multicast filtering hardware setup
From: Rui Sousa <rui.sousa(a)nxp.com>
[ Upstream commit 01f8902bcf3ff124d0aeb88a774180ebcec20ace ]
Fix hardware setup of multicast address hash:
- Never clear the hardware hash (to avoid packet loss)
- Construct the hash register values in software and then write once
to hardware
Signed-off-by: Rui Sousa <rui.sousa(a)nxp.com>
Signed-off-by: Fugang Duan <fugang.duan(a)nxp.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/fec_main.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2793,6 +2793,7 @@ static void set_multicast_list(struct ne
struct netdev_hw_addr *ha;
unsigned int i, bit, data, crc, tmp;
unsigned char hash;
+ unsigned int hash_high = 0, hash_low = 0;
if (ndev->flags & IFF_PROMISC) {
tmp = readl(fep->hwp + FEC_R_CNTRL);
@@ -2815,11 +2816,7 @@ static void set_multicast_list(struct ne
return;
}
- /* Clear filter and add the addresses in hash register
- */
- writel(0, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- writel(0, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
-
+ /* Add the addresses in hash register */
netdev_for_each_mc_addr(ha, ndev) {
/* calculate crc32 value of mac address */
crc = 0xffffffff;
@@ -2837,16 +2834,14 @@ static void set_multicast_list(struct ne
*/
hash = (crc >> (32 - HASH_BITS)) & 0x3f;
- if (hash > 31) {
- tmp = readl(fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- tmp |= 1 << (hash - 32);
- writel(tmp, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- } else {
- tmp = readl(fep->hwp + FEC_GRP_HASH_TABLE_LOW);
- tmp |= 1 << hash;
- writel(tmp, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
- }
+ if (hash > 31)
+ hash_high |= 1 << (hash - 32);
+ else
+ hash_low |= 1 << hash;
}
+
+ writel(hash_high, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
+ writel(hash_low, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
}
/* Set a MAC change in hardware. */
Patches currently in stable-queue which might be from rui.sousa(a)nxp.com are
queue-3.18/net-fec-fix-multicast-filtering-hardware-setup.patch
This is a note to let you know that I've just added the patch titled
mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Wed, 8 Feb 2017 14:30:53 -0800
Subject: mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers
From: Jan Kara <jack(a)suse.cz>
[ Upstream commit 0911d0041c22922228ca52a977d7b0b0159fee4b ]
Some ->page_mkwrite handlers may return VM_FAULT_RETRY as its return
code (GFS2 or Lustre can definitely do this). However VM_FAULT_RETRY
from ->page_mkwrite is completely unhandled by the mm code and results
in locking and writeably mapping the page which definitely is not what
the caller wanted.
Fix Lustre and block_page_mkwrite_ret() used by other filesystems
(notably GFS2) to return VM_FAULT_NOPAGE instead which results in
bailing out from the fault code, the CPU then retries the access, and we
fault again effectively doing what the handler wanted.
Link: http://lkml.kernel.org/r/20170203150729.15863-1-jack@suse.cz
Signed-off-by: Jan Kara <jack(a)suse.cz>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Reviewed-by: Jinshan Xiong <jinshan.xiong(a)intel.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
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/staging/lustre/lustre/llite/llite_mmap.c | 4 +---
include/linux/buffer_head.h | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/staging/lustre/lustre/llite/llite_mmap.c
+++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c
@@ -407,15 +407,13 @@ static int ll_page_mkwrite(struct vm_are
result = VM_FAULT_LOCKED;
break;
case -ENODATA:
+ case -EAGAIN:
case -EFAULT:
result = VM_FAULT_NOPAGE;
break;
case -ENOMEM:
result = VM_FAULT_OOM;
break;
- case -EAGAIN:
- result = VM_FAULT_RETRY;
- break;
default:
result = VM_FAULT_SIGBUS;
break;
--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -236,12 +236,10 @@ static inline int block_page_mkwrite_ret
{
if (err == 0)
return VM_FAULT_LOCKED;
- if (err == -EFAULT)
+ if (err == -EFAULT || err == -EAGAIN)
return VM_FAULT_NOPAGE;
if (err == -ENOMEM)
return VM_FAULT_OOM;
- if (err == -EAGAIN)
- return VM_FAULT_RETRY;
/* -ENOSPC, -EDQUOT, -EIO ... */
return VM_FAULT_SIGBUS;
}
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-3.18/mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch
This is a note to let you know that I've just added the patch titled
ima: fix hash algorithm initialization
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ima-fix-hash-algorithm-initialization.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 5 18:18:39 CET 2017
From: Boshi Wang <wangboshi(a)huawei.com>
Date: Fri, 20 Oct 2017 16:01:03 +0800
Subject: ima: fix hash algorithm initialization
From: Boshi Wang <wangboshi(a)huawei.com>
[ Upstream commit ebe7c0a7be92bbd34c6ff5b55810546a0ee05bee ]
The hash_setup function always sets the hash_setup_done flag, even
when the hash algorithm is invalid. This prevents the default hash
algorithm defined as CONFIG_IMA_DEFAULT_HASH from being used.
This patch sets hash_setup_done flag only for valid hash algorithms.
Fixes: e7a2ad7eb6f4 "ima: enable support for larger default filedata hash algorithms"
Signed-off-by: Boshi Wang <wangboshi(a)huawei.com>
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_main.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -52,6 +52,8 @@ static int __init hash_setup(char *str)
ima_hash_algo = HASH_ALGO_SHA1;
else if (strncmp(str, "md5", 3) == 0)
ima_hash_algo = HASH_ALGO_MD5;
+ else
+ return 1;
goto out;
}
@@ -61,6 +63,8 @@ static int __init hash_setup(char *str)
break;
}
}
+ if (i == HASH_ALGO__LAST)
+ return 1;
out:
hash_setup_done = 1;
return 1;
Patches currently in stable-queue which might be from wangboshi(a)huawei.com are
queue-3.18/ima-fix-hash-algorithm-initialization.patch