This is a note to let you know that I've just added the patch titled
f2fs: fix a bug caused by NULL extent tree
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:
f2fs-fix-a-bug-caused-by-null-extent-tree.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 dad48e73127ba10279ea33e6dbc8d3905c4d31c0 Mon Sep 17 00:00:00 2001
From: Yunlei He <heyunlei(a)huawei.com>
Date: Fri, 19 May 2017 15:06:12 +0800
Subject: f2fs: fix a bug caused by NULL extent tree
From: Yunlei He <heyunlei(a)huawei.com>
commit dad48e73127ba10279ea33e6dbc8d3905c4d31c0 upstream.
Thread A: Thread B:
-f2fs_remount
-sbi->mount_opt.opt = 0;
<--- -f2fs_iget
-do_read_inode
-f2fs_init_extent_tree
-F2FS_I(inode)->extent_tree is NULL
-default_options && parse_options
-remount return
<--- -f2fs_map_blocks
-f2fs_lookup_extent_tree
-f2fs_bug_on(sbi, !et);
The same problem with f2fs_new_inode.
Signed-off-by: Yunlei He <heyunlei(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/extent_cache.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -177,7 +177,7 @@ static void __drop_largest_extent(struct
}
/* return true, if inode page is changed */
-bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+static bool __f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct extent_tree *et;
@@ -215,6 +215,16 @@ out:
return false;
}
+bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+{
+ bool ret = __f2fs_init_extent_tree(inode, i_ext);
+
+ if (!F2FS_I(inode)->extent_tree)
+ set_inode_flag(inode, FI_NO_EXTENT);
+
+ return ret;
+}
+
static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
struct extent_info *ei)
{
Patches currently in stable-queue which might be from heyunlei(a)huawei.com are
queue-4.9/f2fs-fix-a-bug-caused-by-null-extent-tree.patch
This is a note to let you know that I've just added the patch titled
f2fs: fix a bug caused by NULL extent tree
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:
f2fs-fix-a-bug-caused-by-null-extent-tree.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 dad48e73127ba10279ea33e6dbc8d3905c4d31c0 Mon Sep 17 00:00:00 2001
From: Yunlei He <heyunlei(a)huawei.com>
Date: Fri, 19 May 2017 15:06:12 +0800
Subject: f2fs: fix a bug caused by NULL extent tree
From: Yunlei He <heyunlei(a)huawei.com>
commit dad48e73127ba10279ea33e6dbc8d3905c4d31c0 upstream.
Thread A: Thread B:
-f2fs_remount
-sbi->mount_opt.opt = 0;
<--- -f2fs_iget
-do_read_inode
-f2fs_init_extent_tree
-F2FS_I(inode)->extent_tree is NULL
-default_options && parse_options
-remount return
<--- -f2fs_map_blocks
-f2fs_lookup_extent_tree
-f2fs_bug_on(sbi, !et);
The same problem with f2fs_new_inode.
Signed-off-by: Yunlei He <heyunlei(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/extent_cache.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -172,7 +172,7 @@ void f2fs_drop_largest_extent(struct ino
__drop_largest_extent(inode, fofs, 1);
}
-void f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+static void __f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct extent_tree *et;
@@ -204,6 +204,14 @@ out:
write_unlock(&et->lock);
}
+void f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+{
+ __f2fs_init_extent_tree(inode, i_ext);
+
+ if (!F2FS_I(inode)->extent_tree)
+ set_inode_flag(F2FS_I(inode), FI_NO_EXTENT);
+}
+
static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
struct extent_info *ei)
{
Patches currently in stable-queue which might be from heyunlei(a)huawei.com are
queue-4.4/f2fs-fix-a-bug-caused-by-null-extent-tree.patch
This is a note to let you know that I've just added the patch titled
i2c: designware: must wait for enable
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-designware-must-wait-for-enable.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 fba4adbbf670577e605f9ad306629db6031cd48b Mon Sep 17 00:00:00 2001
From: Ben Gardner <gardner.ben(a)gmail.com>
Date: Wed, 14 Feb 2018 09:29:52 -0600
Subject: i2c: designware: must wait for enable
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ben Gardner <gardner.ben(a)gmail.com>
commit fba4adbbf670577e605f9ad306629db6031cd48b upstream.
One I2C bus on my Atom E3845 board has been broken since 4.9.
It has two devices, both declared by ACPI and with built-in drivers.
There are two back-to-back transactions originating from the kernel, one
targeting each device. The first transaction works, the second one locks
up the I2C controller. The controller never recovers.
These kernel logs show up whenever an I2C transaction is attempted after
this failure.
i2c-designware-pci 0000:00:18.3: timeout in disabling adapter
i2c-designware-pci 0000:00:18.3: timeout waiting for bus ready
Waiting for the I2C controller status to indicate that it is enabled
before programming it fixes the issue.
I have tested this patch on 4.14 and 4.15.
Fixes: commit 2702ea7dbec5 ("i2c: designware: wait for disable/enable only if necessary")
Cc: linux-stable <stable(a)vger.kernel.org> #4.13+
Signed-off-by: Ben Gardner <gardner.ben(a)gmail.com>
Acked-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza(a)intel.com>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Signed-off-by: Ben Gardner <gardner.ben(a)gmail.com>
[Jarkko: Backported to v4.9..v4.12 before i2c-designware-core.c was renamed to i2c-designware-master.c]
Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/busses/i2c-designware-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -507,7 +507,7 @@ static void i2c_dw_xfer_init(struct dw_i
i2c_dw_disable_int(dev);
/* Enable the adapter */
- __i2c_dw_enable(dev, true);
+ __i2c_dw_enable_and_wait(dev, true);
/* Clear and enable interrupts */
dw_readl(dev, DW_IC_CLR_INTR);
Patches currently in stable-queue which might be from gardner.ben(a)gmail.com are
queue-4.9/i2c-designware-must-wait-for-enable.patch
Requesting backport of:
174134ac760275457bb0d1560a0dbe6cf8a12ad6
ipmi_si: Fix error handling of platform device
to 4.15 only. Without it, an oops can occur in certain
situations.
Thanks,
-corey
This is a note to let you know that I've just added the patch titled
ipmi_si: Fix error handling of platform device
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipmi_si-fix-error-handling-of-platform-device.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 174134ac760275457bb0d1560a0dbe6cf8a12ad6 Mon Sep 17 00:00:00 2001
From: Corey Minyard <cminyard(a)mvista.com>
Date: Mon, 27 Nov 2017 08:18:33 -0600
Subject: ipmi_si: Fix error handling of platform device
From: Corey Minyard <cminyard(a)mvista.com>
commit 174134ac760275457bb0d1560a0dbe6cf8a12ad6 upstream.
Cleanup of platform devices created by the IPMI driver was not
being done correctly and could result in a memory leak. So
create a local boolean to know how to clean up those platform
devices.
Reported-by: David Binderman <dcb314(a)hotmail.com>
Signed-off-by: Corey Minyard <cminyard(a)mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/ipmi/ipmi_si_intf.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2045,6 +2045,7 @@ static int try_smi_init(struct smi_info
int rv = 0;
int i;
char *init_name = NULL;
+ bool platform_device_registered = false;
pr_info(PFX "Trying %s-specified %s state machine at %s address 0x%lx, slave address 0x%x, irq %d\n",
ipmi_addr_src_to_str(new_smi->io.addr_source),
@@ -2173,6 +2174,7 @@ static int try_smi_init(struct smi_info
rv);
goto out_err;
}
+ platform_device_registered = true;
}
dev_set_drvdata(new_smi->io.dev, new_smi);
@@ -2279,10 +2281,11 @@ out_err:
}
if (new_smi->pdev) {
- platform_device_unregister(new_smi->pdev);
+ if (platform_device_registered)
+ platform_device_unregister(new_smi->pdev);
+ else
+ platform_device_put(new_smi->pdev);
new_smi->pdev = NULL;
- } else if (new_smi->pdev) {
- platform_device_put(new_smi->pdev);
}
kfree(init_name);
Patches currently in stable-queue which might be from cminyard(a)mvista.com are
queue-4.15/ipmi_si-fix-error-handling-of-platform-device.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 9f2068f35729948bde84d87a40d135015911345d Mon Sep 17 00:00:00 2001
From: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Date: Tue, 13 Feb 2018 15:04:46 +0100
Subject: serial: 8250_pci: Add Brainboxes UC-260 4 port serial device
Add PCI ids for two variants of Brainboxes UC-260 quad port
PCI serial cards.
Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_pci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index d580625acc79..a93f77ab3da0 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -4702,6 +4702,17 @@ static const struct pci_device_id serial_pci_tbl[] = {
{ PCI_VENDOR_ID_INTASHIELD, PCI_DEVICE_ID_INTASHIELD_IS400,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */
pbn_b2_4_115200 },
+ /*
+ * BrainBoxes UC-260
+ */
+ { PCI_VENDOR_ID_INTASHIELD, 0x0D21,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
+ { PCI_VENDOR_ID_INTASHIELD, 0x0E34,
+ PCI_ANY_ID, PCI_ANY_ID,
+ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+ pbn_b2_4_115200 },
/*
* Perle PCI-RAS cards
*/
--
2.16.2
This is a note to let you know that I've just added the patch titled
serial: sh-sci: prevent lockup on full TTY buffers
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7842055bfce4bf0170d0f61df8b2add8399697be Mon Sep 17 00:00:00 2001
From: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Date: Thu, 15 Feb 2018 13:02:27 +0100
Subject: serial: sh-sci: prevent lockup on full TTY buffers
When the TTY buffers fill up to the configured maximum, a system lockup
occurs:
[ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[ 598.838755] Task dump for CPU 0:
[ 598.841977] swapper/0 R running task 0 0 0 0x00000022
[ 598.849023] Call trace:
[ 598.851476] __switch_to+0x98/0xb0
[ 598.854870] (null)
This can be prevented by doing a dummy read of the RX data register.
This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Cc: stable <stable(a)vger.kernel.org>
Tested-by: Nguyen Viet Dung <dung.nguyen.aj(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 7257c078e155..44adf9db38f8 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -885,6 +885,8 @@ static void sci_receive_chars(struct uart_port *port)
/* Tell the rest of the system the news. New characters! */
tty_flip_buffer_push(tport);
} else {
+ /* TTY buffers full; read from RX reg to prevent lockup */
+ serial_port_in(port, SCxRDR);
serial_port_in(port, SCxSR); /* dummy read */
sci_clear_SCxSR(port, SCxSR_RDxF_CLEAR(port));
}
--
2.16.2
This is a note to let you know that I've just added the patch titled
serial: core: mark port as initialized in autoconfig
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 714569064adee3c114a2a6490735b94abe269068 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Date: Sat, 3 Feb 2018 12:27:23 +0100
Subject: serial: core: mark port as initialized in autoconfig
This is a followup on 44117a1d1732 ("serial: core: mark port as
initialized after successful IRQ change").
Nikola has been using autoconfig via setserial and reported a crash
similar to what I fixed in the earlier mentioned commit. Here I do the
same fixup for the autoconfig. I wasn't sure that this is the right
approach. Nikola confirmed that it fixes his crash.
Fixes: b3b576461864 ("tty: serial_core: convert uart_open to use tty_port_open")
Link: http://lkml.kernel.org/r/20180131072000.GD1853@localhost.localdomain
Reported-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Tested-by: Nikola Ciprich <nikola.ciprich(a)linuxbox.cz>
Acked-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/serial_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index c8dde56b532b..35b9201db3b4 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1144,6 +1144,8 @@ static int uart_do_autoconfig(struct tty_struct *tty,struct uart_state *state)
uport->ops->config_port(uport, flags);
ret = uart_startup(tty, state, 1);
+ if (ret == 0)
+ tty_port_set_initialized(port, true);
if (ret > 0)
ret = 0;
}
--
2.16.2
This is a note to let you know that I've just added the patch titled
tty/serial: atmel: add new version check for usart
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 Mon Sep 17 00:00:00 2001
From: Jonas Danielsson <jonas(a)orbital-systems.com>
Date: Mon, 29 Jan 2018 12:39:15 +0100
Subject: tty/serial: atmel: add new version check for usart
On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.
Signed-off-by: Jonas Danielsson <jonas(a)orbital-systems.com>
Acked-by: Richard Genoud <richard.genoud(a)gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index df46a9e88c34..e287fe8f10fc 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1734,6 +1734,7 @@ static void atmel_get_ip_name(struct uart_port *port)
switch (version) {
case 0x302:
case 0x10213:
+ case 0x10302:
dev_dbg(port->dev, "This version is usart\n");
atmel_port->has_frac_baudrate = true;
atmel_port->has_hw_timer = true;
--
2.16.2
It will get the wrong virtual address because port->mapbase is not added
the correct reg-offset yet. We have to update it before earlycon_map()
is called
Signed-off-by: Greentime Hu <greentime(a)andestech.com>
Acked-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Peter Hurley <peter(a)hurleysoftware.com>
Cc: stable(a)vger.kernel.org
Fixes: 088da2a17619 ("of: earlycon: Initialize port fields from DT
properties")
---
drivers/tty/serial/earlycon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 870e84fb6e39..a24278380fec 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -245,11 +245,12 @@ int __init of_setup_earlycon(const struct earlycon_id *match,
}
port->mapbase = addr;
port->uartclk = BASE_BAUD * 16;
- port->membase = earlycon_map(port->mapbase, SZ_4K);
val = of_get_flat_dt_prop(node, "reg-offset", NULL);
if (val)
port->mapbase += be32_to_cpu(*val);
+ port->membase = earlycon_map(port->mapbase, SZ_4K);
+
val = of_get_flat_dt_prop(node, "reg-shift", NULL);
if (val)
port->regshift = be32_to_cpu(*val);
--
2.16.1
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
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:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.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 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1134,7 +1134,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-4.9/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
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:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.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 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1139,7 +1139,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-4.4/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1104,7 +1104,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-4.15/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
This is the start of the stable review cycle for the 4.4.119 release.
There are 22 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Feb 28 20:15:48 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.119-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.4.119-rc1
Eric Biggers <ebiggers(a)google.com>
binder: add missing binder_unlock()
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Process all descriptors during bind
Karsten Koop <kkoop(a)ld-didactic.de>
usb: ldusb: add PIDs for new CASSY devices supported by this driver
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: gadget: Set maxpacket size for ep0 IN
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
Jack Stocker <jackstocker.93(a)gmail.com>
Add delay-init quirk for Corsair K70 RGB keyboards
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Disable unhandled signal log messages by default
AMAN DEEP <aman.deep(a)samsung.com>
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
Shanker Donthineni <shankerd(a)codeaurora.org>
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
Arnd Bergmann <arnd(a)arndb.de>
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
Lars-Peter Clausen <lars(a)metafoo.de>
iio: adis_lib: Initialize trigger before requesting interrupt
Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
iio: buffer: check if a buffer has been set up when poll is called
Arnd Bergmann <arnd(a)arndb.de>
cfg80211: fix cfg80211_beacon_dup
Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix high memory/reserved memory collision
Paolo Abeni <pabeni(a)redhat.com>
ip_tunnel: fix preempt warning in ip tunnel creation/updating
Paolo Abeni <pabeni(a)redhat.com>
ip_tunnel: replace dst_cache with generic implementation
Johan Hovold <johan(a)kernel.org>
PCI: keystone: Fix interrupt-controller-node lookup
Michael Ellerman <mpe(a)ellerman.id.au>
powerpc/64s: Fix RFI flush dependency on HARDLOCKUP_DETECTOR
Paolo Abeni <pabeni(a)redhat.com>
netfilter: drop outermost socket lock in getsockopt()
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/kernel/traps.c | 2 +-
arch/powerpc/kernel/setup_64.c | 2 +-
arch/x86/oprofile/nmi_int.c | 2 +-
arch/xtensa/mm/init.c | 70 ++++++++++++++++++++++++---
drivers/android/binder.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -
drivers/gpu/drm/drm_edid.c | 3 ++
drivers/hid/hid-core.c | 3 ++
drivers/hid/hid-ids.h | 3 ++
drivers/iio/imu/adis_trigger.c | 7 +--
drivers/iio/industrialio-buffer.c | 2 +-
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/pci/host/pci-keystone.c | 9 +++-
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
drivers/usb/core/quirks.c | 3 ++
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/gadget/function/f_fs.c | 6 +--
drivers/usb/host/ohci-q.c | 17 ++++---
drivers/usb/misc/ldusb.c | 6 +++
drivers/usb/renesas_usbhs/fifo.c | 5 ++
include/net/ip_tunnels.h | 9 +---
net/ipv4/Kconfig | 1 +
net/ipv4/ip_sockglue.c | 7 +--
net/ipv4/ip_tunnel.c | 78 +++++-------------------------
net/ipv6/ipv6_sockglue.c | 10 +---
net/ipv6/sit.c | 17 ++++---
net/mac80211/cfg.c | 2 +-
28 files changed, 151 insertions(+), 129 deletions(-)
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
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:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.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 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1106,7 +1106,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-4.14/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
This is a note to let you know that I've just added the patch titled
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
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:
hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.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 48d0c9becc7f3c66874c100c126459a9da0fdced Mon Sep 17 00:00:00 2001
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Date: Thu, 21 Dec 2017 11:41:35 +0100
Subject: hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
From: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Signed-off-by: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: keescook(a)chromium.org
Fixes: 597d0275736d ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1149,7 +1149,12 @@ static void __hrtimer_init(struct hrtime
cpu_base = raw_cpu_ptr(&hrtimer_bases);
- if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
+ /*
+ * POSIX magic: Relative CLOCK_REALTIME timers are not affected by
+ * clock modifications, so they needs to become CLOCK_MONOTONIC to
+ * ensure POSIX compliance.
+ */
+ if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL)
clock_id = CLOCK_MONOTONIC;
base = hrtimer_clockid_to_base(clock_id);
Patches currently in stable-queue which might be from anna-maria(a)linutronix.de are
queue-3.18/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel
and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool:
lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool:
x509_note_pkey_algo()+0xa4: sibling call from callable instruction
with modified stack frame
drivers/infiniband/hw/bnxt_re/qplib_fp.o: warning: objtool:
bnxt_qplib_poll_cq()+0x106: sibling call from callable instruction
with modified stack frame
It's likely that this is the complete set at the moment, I saw each
one multiple times,
but did not see any others. I'll reply with the respective object
files for your reference,
in case these are so far unknown to you. There are only a handful of randconfig
warnings we see overall in the kernel these days (at least on x86 and arm64), so
even if they are false-positive, it would be great to get rid of the
output so we can
do randconfig testing on 4.14.y and treat any output from 'make -s' as
a regression.
I did not check
With gcc-8, things are looking very differently, and we still get an
endless supply of
similar warnings.
Arnd
The patch
spi: atmel: init FIFOs before spi enable
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9581329eff9db72ab4fbb46a594fd7fdda3c51b0 Mon Sep 17 00:00:00 2001
From: Eugen Hristev <eugen.hristev(a)microchip.com>
Date: Tue, 27 Feb 2018 12:25:07 +0200
Subject: [PATCH] spi: atmel: init FIFOs before spi enable
The datasheet recommends initializing FIFOs before
SPI enable. If we do not do it like this, there may be
a strange behavior. We noticed that DMA does not work properly
with FIFOs if we do not clear them beforehand or enable them
before SPIEN.
Signed-off-by: Eugen Hristev <eugen.hristev(a)microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/spi/spi-atmel.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 4a11fc0d4136..b7936f815373 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1512,6 +1512,11 @@ static void atmel_spi_init(struct atmel_spi *as)
{
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
+
+ /* It is recommended to enable FIFOs first thing after reset */
+ if (as->fifo_size)
+ spi_writel(as, CR, SPI_BIT(FIFOEN));
+
if (as->caps.has_wdrbt) {
spi_writel(as, MR, SPI_BIT(WDRBT) | SPI_BIT(MODFDIS)
| SPI_BIT(MSTR));
@@ -1522,9 +1527,6 @@ static void atmel_spi_init(struct atmel_spi *as)
if (as->use_pdc)
spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
spi_writel(as, CR, SPI_BIT(SPIEN));
-
- if (as->fifo_size)
- spi_writel(as, CR, SPI_BIT(FIFOEN));
}
static int atmel_spi_probe(struct platform_device *pdev)
--
2.16.1
The patch
ASoC: wm_adsp: For TLV controls only register TLV get/set
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d7789f5bcdb298c4a302db471b1b20f74a20de95 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Date: Wed, 28 Feb 2018 10:31:10 +0000
Subject: [PATCH] ASoC: wm_adsp: For TLV controls only register TLV get/set
Normal 512-byte get/set of a TLV isn't supported but we were
registering the normal get/set anyway and relying on omitting
the SNDRV_CTL_ELEM_ACCESS_[READ|WRITE] flags to prevent them
being called.
Trouble is if this gets broken in the core ALSA code - as it has
been since at least 4.14 - the standard get/set can be called
unexpectedly and corrupt memory.
There's no point providing functions that won't be called and
it's a trivial change. The benefit is that if the ALSA core gets
broken again we get a big fat immediate NULL dereference instead
of a memory corruption timebomb.
Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/codecs/wm_adsp.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index 66e32f5d2917..989d093abda7 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -1204,12 +1204,14 @@ static int wmfw_add_ctl(struct wm_adsp *dsp, struct wm_coeff_ctl *ctl)
kcontrol->put = wm_coeff_put_acked;
break;
default:
- kcontrol->get = wm_coeff_get;
- kcontrol->put = wm_coeff_put;
-
- ctl->bytes_ext.max = ctl->len;
- ctl->bytes_ext.get = wm_coeff_tlv_get;
- ctl->bytes_ext.put = wm_coeff_tlv_put;
+ if (kcontrol->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
+ ctl->bytes_ext.max = ctl->len;
+ ctl->bytes_ext.get = wm_coeff_tlv_get;
+ ctl->bytes_ext.put = wm_coeff_tlv_put;
+ } else {
+ kcontrol->get = wm_coeff_get;
+ kcontrol->put = wm_coeff_put;
+ }
break;
}
--
2.16.1
On Fri, Feb 23, 2018 at 06:29:02PM +0000, Ard Biesheuvel wrote:
> Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
> to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
> not survive the backporting process unscathed, and ends up writing garbage
> into the TTBR1_EL1 register, rather than pointing it to the zero page to
> disable translations. Fix that.
>
> Cc: <stable(a)vger.kernel.org> #v4.14
> Reported-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
> ---
> arch/arm64/mm/proc.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Any reason why you didn't cc: the stable list, as this is a patch that
is not needed in mainline, right?
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 08572f95bd8a..2b473ddeb7a3 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -155,7 +155,7 @@ ENDPROC(cpu_do_switch_mm)
>
> .macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
> adrp \tmp1, empty_zero_page
> - msr ttbr1_el1, \tmp2
> + msr ttbr1_el1, \tmp1
I don't understand why this isn't also needed in Linus's tree. What
commit there prevents this from being required?
thanks,
greg k-h
This is a note to let you know that I've just added the patch titled
vsprintf: avoid misleading "(null)" for %px
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
vsprintf-avoid-misleading-null-for-px.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3a129cc2151425e5aeb69aeb25fbc994ec738137 Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilobyte(a)angband.pl>
Date: Sun, 4 Feb 2018 18:45:21 +0100
Subject: vsprintf: avoid misleading "(null)" for %px
From: Adam Borowski <kilobyte(a)angband.pl>
commit 3a129cc2151425e5aeb69aeb25fbc994ec738137 upstream.
Like %pK already does, print "00000000" instead.
This confused people -- the convention is that "(null)" means you tried to
dereference a null pointer as opposed to printing the address.
Link: http://lkml.kernel.org/r/20180204174521.21383-1-kilobyte@angband.pl
To: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
To: Steven Rostedt <rostedt(a)goodmis.org>
To: linux-kernel(a)vger.kernel.org
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Joe Perches <joe(a)perches.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: "Roberts, William C" <william.c.roberts(a)intel.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: David Laight <David.Laight(a)ACULAB.COM>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Geert Uytterhoeven <geert(a)linux-m68k.org>
Signed-off-by: Adam Borowski <kilobyte(a)angband.pl>
Signed-off-by: Petr Mladek <pmladek(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/vsprintf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1849,7 +1849,7 @@ char *pointer(const char *fmt, char *buf
{
const int default_width = 2 * sizeof(void *);
- if (!ptr && *fmt != 'K') {
+ if (!ptr && *fmt != 'K' && *fmt != 'x') {
/*
* Print (null) with the same width as a pointer so it makes
* tabular output look nice.
Patches currently in stable-queue which might be from kilobyte(a)angband.pl are
queue-4.15/vsprintf-avoid-misleading-null-for-px.patch
Hi,
Please include 3a129cc21514 ("vsprintf: avoid misleading "(null)" for
%px") in the 4.15 stable tree. That patch should have had these
fields:
Fixes: 668533dc0764 ("kallsyms: take advantage of the new '%px' format")
Cc: stable(a)vger.kernel.org
But I didn't notice when it went by originally. (Thanks to Steve for
pointing this out as being missed for 4.15.) :)
Thanks!
-Kees
--
Kees Cook
Pixel Security
This is a note to let you know that I've just added the patch titled
ipv6: Skip XFRM lookup if dst_entry in socket cache is valid
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:
ipv6-skip-xfrm-lookup-if-dst_entry-in-socket-cache-is-valid.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 00bc0ef5880dc7b82f9c320dead4afaad48e47be Mon Sep 17 00:00:00 2001
From: Jakub Sitnicki <jkbs(a)redhat.com>
Date: Wed, 8 Jun 2016 15:13:34 +0200
Subject: ipv6: Skip XFRM lookup if dst_entry in socket cache is valid
From: Jakub Sitnicki <jkbs(a)redhat.com>
commit 00bc0ef5880dc7b82f9c320dead4afaad48e47be upstream.
At present we perform an xfrm_lookup() for each UDPv6 message we
send. The lookup involves querying the flow cache (flow_cache_lookup)
and, in case of a cache miss, creating an XFRM bundle.
If we miss the flow cache, we can end up creating a new bundle and
deriving the path MTU (xfrm_init_pmtu) from on an already transformed
dst_entry, which we pass from the socket cache (sk->sk_dst_cache) down
to xfrm_lookup(). This can happen only if we're caching the dst_entry
in the socket, that is when we're using a connected UDP socket.
To put it another way, the path MTU shrinks each time we miss the flow
cache, which later on leads to incorrectly fragmented payload. It can
be observed with ESPv6 in transport mode:
1) Set up a transformation and lower the MTU to trigger fragmentation
# ip xfrm policy add dir out src ::1 dst ::1 \
tmpl src ::1 dst ::1 proto esp spi 1
# ip xfrm state add src ::1 dst ::1 \
proto esp spi 1 enc 'aes' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
# ip link set dev lo mtu 1500
2) Monitor the packet flow and set up an UDP sink
# tcpdump -ni lo -ttt &
# socat udp6-listen:12345,fork /dev/null &
3) Send a datagram that needs fragmentation with a connected socket
# perl -e 'print "@" x 1470 | socat - udp6:[::1]:12345
2016/06/07 18:52:52 socat[724] E read(3, 0x555bb3d5ba00, 8192): Protocol error
00:00:00.000000 IP6 ::1 > ::1: frag (0|1448) ESP(spi=0x00000001,seq=0x2), length 1448
00:00:00.000014 IP6 ::1 > ::1: frag (1448|32)
00:00:00.000050 IP6 ::1 > ::1: ESP(spi=0x00000001,seq=0x3), length 1272
(^ ICMPv6 Parameter Problem)
00:00:00.000022 IP6 ::1 > ::1: ESP(spi=0x00000001,seq=0x5), length 136
4) Compare it to a non-connected socket
# perl -e 'print "@" x 1500' | socat - udp6-sendto:[::1]:12345
00:00:40.535488 IP6 ::1 > ::1: frag (0|1448) ESP(spi=0x00000001,seq=0x6), length 1448
00:00:00.000010 IP6 ::1 > ::1: frag (1448|64)
What happens in step (3) is:
1) when connecting the socket in __ip6_datagram_connect(), we
perform an XFRM lookup, miss the flow cache, create an XFRM
bundle, and cache the destination,
2) afterwards, when sending the datagram, we perform an XFRM lookup,
again, miss the flow cache (due to mismatch of flowi6_iif and
flowi6_oif, which is an issue of its own), and recreate an XFRM
bundle based on the cached (and already transformed) destination.
To prevent the recreation of an XFRM bundle, avoid an XFRM lookup
altogether whenever we already have a destination entry cached in the
socket. This prevents the path MTU shrinkage and brings us on par with
UDPv4.
The fix also benefits connected PINGv6 sockets, another user of
ip6_sk_dst_lookup_flow(), who also suffer messages being transformed
twice.
Joint work with Hannes Frederic Sowa.
Reported-by: Jan Tluka <jtluka(a)redhat.com>
Signed-off-by: Jakub Sitnicki <jkbs(a)redhat.com>
Acked-by: Hannes Frederic Sowa <hannes(a)stressinduktion.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Benedict Wong <benedictwong(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_output.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1038,17 +1038,12 @@ struct dst_entry *ip6_sk_dst_lookup_flow
const struct in6_addr *final_dst)
{
struct dst_entry *dst = sk_dst_check(sk, inet6_sk(sk)->dst_cookie);
- int err;
dst = ip6_sk_dst_check(sk, dst, fl6);
+ if (!dst)
+ dst = ip6_dst_lookup_flow(sk, fl6, final_dst);
- err = ip6_dst_lookup_tail(sk, &dst, fl6);
- if (err)
- return ERR_PTR(err);
- if (final_dst)
- fl6->daddr = *final_dst;
-
- return xfrm_lookup_route(sock_net(sk), dst, flowi6_to_flowi(fl6), sk, 0);
+ return dst;
}
EXPORT_SYMBOL_GPL(ip6_sk_dst_lookup_flow);
Patches currently in stable-queue which might be from jkbs(a)redhat.com are
queue-3.18/ipv6-skip-xfrm-lookup-if-dst_entry-in-socket-cache-is-valid.patch
This is the start of the stable review cycle for the 4.14.23 release.
There are 54 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Feb 28 20:21:22 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.23-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.23-rc1
Chris Wilson <chris(a)chris-wilson.co.uk>
drm/i915/breadcrumbs: Ignore unsubmitted signalers
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/amdgpu: add new device to use atpx quirk
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: add atpx quirk handling (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Add dpm quirk for Jet PRO (v2)
Huang Rui <ray.huang(a)amd.com>
drm/amdgpu: disable MMHUB power gating on raven
Chris Wilson <chris(a)chris-wilson.co.uk>
drm: Handle unexpected holes in color-eviction
Daniel Vetter <daniel.vetter(a)ffwll.ch>
drm/cirrus: Load lut in crtc_commit
Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Use config_ep_by_speed()
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Process all descriptors during bind
Bin Liu <b-liu(a)ti.com>
Revert "usb: musb: host: don't start next rx urb if current one failed"
Karsten Koop <kkoop(a)ld-didactic.de>
usb: ldusb: add PIDs for new CASSY devices supported by this driver
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: ep0: Reset TRB counter for ep0 IN
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: gadget: Set maxpacket size for ep0 IN
Peter Chen <hzpeterchen(a)gmail.com>
usb: host: ehci: use correct device pointer for dma ops
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
Jack Stocker <jackstocker.93(a)gmail.com>
Add delay-init quirk for Corsair K70 RGB keyboards
Will Deacon <will.deacon(a)arm.com>
arm64: cpufeature: Fix CTR_EL0 field definitions
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Disable unhandled signal log messages by default
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Remove unimplemented syscall log message
AMAN DEEP <aman.deep(a)samsung.com>
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
Casey Leedom <leedom(a)chelsio.com>
PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
Matt Redfearn <matt.redfearn(a)mips.com>
irqchip/mips-gic: Avoid spuriously handling masked interrupts
Shanker Donthineni <shankerd(a)codeaurora.org>
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
Huang Ying <huang.ying.caritas(a)gmail.com>
mm, swap, frontswap: fix THP swap if frontswap enabled
Arnd Bergmann <arnd(a)arndb.de>
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
Arnd Bergmann <arnd(a)arndb.de>
Kbuild: always define endianess in kconfig.h
Lars-Peter Clausen <lars(a)metafoo.de>
iio: adis_lib: Initialize trigger before requesting interrupt
Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
iio: buffer: check if a buffer has been set up when poll is called
Andreas Klinger <ak(a)it-klinger.de>
iio: srf08: fix link error "devm_iio_triggered_buffer_setup" undefined
Fabrice Gasnier <fabrice.gasnier(a)st.com>
iio: adc: stm32: fix stm32h7_adc_enable error handling
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Sanitize user entered port numbers prior to access it
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Fix circular locking dependency
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Fix bad unlock balance in ib_uverbs_close_xrcd
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Protect from command mask overflow
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Protect from races between lookup and destroy of uobjects
Hans de Goede <hdegoede(a)redhat.com>
extcon: int3496: process id-pin first so that we start with the right status
Eric Biggers <ebiggers(a)google.com>
PKCS#7: fix certificate blacklisting
Eric Biggers <ebiggers(a)google.com>
PKCS#7: fix certificate chain verification
Eric Biggers <ebiggers(a)google.com>
X.509: fix NULL dereference when restricting key with unsupported_sig
Eric Biggers <ebiggers(a)google.com>
X.509: fix BUG_ON() when hash algorithm is unsupported
Eric Anholt <eric(a)anholt.net>
i2c: bcm2835: Set up the rising/falling edge delays
Ben Gardner <gardner.ben(a)gmail.com>
i2c: designware: must wait for enable
Arnd Bergmann <arnd(a)arndb.de>
cfg80211: fix cfg80211_beacon_dup
James Hogan <jhogan(a)kernel.org>
MIPS: Drop spurious __unused in struct compat_flock
Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix high memory/reserved memory collision
Kees Cook <keescook(a)chromium.org>
MIPS: boot: Define __ASSEMBLY__ for its.S build
Kees Cook <keescook(a)chromium.org>
kconfig.h: Include compiler types to avoid missed struct attributes
Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
arm64: mm: don't write garbage into TTBR1_EL1 register
Paolo Abeni <pabeni(a)redhat.com>
netfilter: drop outermost socket lock in getsockopt()
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/kernel/cpufeature.c | 6 +-
arch/arm64/kernel/traps.c | 10 +---
arch/arm64/mm/proc.S | 2 +-
arch/mips/boot/Makefile | 1 +
arch/mips/include/asm/compat.h | 1 -
arch/x86/oprofile/nmi_int.c | 2 +-
arch/xtensa/mm/init.c | 70 +++++++++++++++++++++---
crypto/asymmetric_keys/pkcs7_verify.c | 12 ++--
crypto/asymmetric_keys/public_key.c | 4 +-
crypto/asymmetric_keys/restrict.c | 21 ++++---
drivers/extcon/extcon-intel-int3496.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 58 +++++++++++++++++---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 ++
drivers/gpu/drm/amd/amdgpu/soc15.c | 4 +-
drivers/gpu/drm/amd/amdgpu/vi.c | 21 ++++---
drivers/gpu/drm/cirrus/cirrus_mode.c | 40 ++++++++------
drivers/gpu/drm/drm_edid.c | 3 +
drivers/gpu/drm/drm_mm.c | 21 ++++++-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 29 ++++------
drivers/hid/hid-core.c | 3 +
drivers/hid/hid-ids.h | 3 +
drivers/i2c/busses/i2c-bcm2835.c | 21 ++++++-
drivers/i2c/busses/i2c-designware-master.c | 2 +-
drivers/iio/adc/stm32-adc.c | 7 ++-
drivers/iio/imu/adis_trigger.c | 7 ++-
drivers/iio/industrialio-buffer.c | 2 +-
drivers/iio/proximity/Kconfig | 2 +
drivers/infiniband/core/rdma_core.c | 10 +++-
drivers/infiniband/core/uverbs_cmd.c | 16 ++++--
drivers/infiniband/core/uverbs_main.c | 27 ++++++---
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/irqchip/irq-mips-gic.c | 2 -
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 ----
drivers/pci/quirks.c | 39 +++++++------
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
drivers/usb/core/quirks.c | 3 +
drivers/usb/dwc3/ep0.c | 7 ++-
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/gadget/function/f_fs.c | 44 +++------------
drivers/usb/host/ehci-hub.c | 4 +-
drivers/usb/host/ohci-hcd.c | 10 +++-
drivers/usb/host/ohci-hub.c | 4 +-
drivers/usb/host/ohci-q.c | 17 +++---
drivers/usb/misc/ldusb.c | 6 ++
drivers/usb/musb/musb_host.c | 8 +--
drivers/usb/renesas_usbhs/fifo.c | 5 ++
drivers/xen/tmem.c | 4 ++
include/linux/kconfig.h | 9 +++
mm/zswap.c | 6 ++
net/ipv4/ip_sockglue.c | 7 +--
net/ipv6/ipv6_sockglue.c | 10 +---
net/mac80211/cfg.c | 2 +-
54 files changed, 403 insertions(+), 219 deletions(-)
On 2/27/18 7:57 AM, Mark Brown wrote:
> On Tue, Feb 27, 2018 at 07:13:17AM -0800, Pierre-Louis Bossart wrote:
>> On 2/27/18 2:38 AM, Mark Brown wrote:
>>> On Mon, Feb 26, 2018 at 06:30:15PM -0800, Pierre-Louis Bossart wrote:
>
>>>> This issue was found during the development of SOF (Sound Open Firmware)
>>>> where we get the reverse of the intended behavior when using the same
>>>> conventions in topology files as in machine drivers.
>
>>> Is this perhaps something that the earlier firmware is handling inside
>>> the firmware?
>
>> For SKL+ the SSP settings come from binary blobs read from ACPI/NHLT tables
>> so I am wondering if this inversion is compensated for in the tools used to
>> generate the blobs.
>
> Ugh, I'm confused here. Is this a case of SoF differing from the
> regular firmware somehow - presumably the stuff coming from the NHLT
> table is the same for both firmwares?
no we are not using the NHLT info for now but using the one provided in
topology files. the SOF firmware does not rely on blobs but programs the
registers based on masks and settings passed. This difference is
precisely how we exposed a difference in behavior.
Hi All,
This backport patchset fixed the spectre issue, it's original branch:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti
A few dependency or fixingpatches are also picked up, if they are necessary
or no functional changes.
arm64: cpu_errata: Allow an erratum to be match for all revisions of a core
arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early
arm64: syscallno is secretly an int, make it official
arm64: uaccess: consistently check object sizes
arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm macro
arm64: Factor out PAN enabling/disabling into separate uaccess_* macros
arm64: move TASK_* definitions to <asm/processor.h>
arm64: alternatives: apply boot time fixups via the linear mapping
mm: Introduce lm_alias
The patchset also on repository:
git://git.linaro.org/kernel/linux-linaro-stable.git lts-4.9-spectrevv2
The kernelci.org and lkft testing show no regressions.
Any comments are appreciated!
Regards
Alex
---
Ard Biesheuvel <ard.biesheuvel(a)linaro.org> (1):
arm64: alternatives: apply boot time fixups via the linear mapping
Catalin Marinas <catalin.marinas(a)arm.com> (2):
arm64: Factor out PAN enabling/disabling into separate uaccess_* macros
arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm macro
Dave Martin <Dave.Martin(a)arm.com> (1):
arm64: syscallno is secretly an int, make it official
James Morse <james.morse(a)arm.com> (1):
arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early
Laura Abbott <labbott(a)redhat.com> (1):
mm: Introduce lm_alias
Marc Zyngier <marc.zyngier(a)arm.com> (26):
arm64: cpu_errata: Allow an erratum to be match for all revisions of a core
arm64: Move post_ttbr_update_workaround to C code
arm64: Move BP hardening to check_and_switch_context
arm64: KVM: Use per-CPU vector when BP hardening is enabled
arm64: KVM: Increment PC after handling an SMC trap
arm/arm64: KVM: Consolidate the PSCI include files
arm/arm64: KVM: Add PSCI_VERSION helper
arm/arm64: KVM: Add smccc accessors to PSCI code
arm/arm64: KVM: Implement PSCI 1.0 support
arm/arm64: KVM: Advertise SMCCC v1.1
arm64: KVM: Make PSCI_VERSION a fast path
arm/arm64: KVM: Turn kvm_psci_version into a static inline
arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support
arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling
firmware/psci: Expose PSCI conduit
firmware/psci: Expose SMCCC version through psci_ops
arm/arm64: smccc: Make function identifiers an unsigned quantity
arm/arm64: smccc: Implement SMCCC v1.1 inline primitive
arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support
arm64: Kill PSCI_GET_VERSION as a variant-2 workaround
arm: Add BTB invalidation on switch_mm for Cortex-A9, A12 and A17
arm: Invalidate BTB on prefetch abort outside of user mapping on Cortex A8, A9, A12 and A17
arm: KVM: Invalidate BTB on guest exit for Cortex-A12/A17
arm: Add icache invalidation on switch_mm for Cortex-A15
arm: Invalidate icache on prefetch abort outside of user mapping on Cortex-A15
arm: KVM: Invalidate icache on guest exit for Cortex-A15
Mark Rutland <mark.rutland(a)arm.com> (1):
arm64: uaccess: consistently check object sizes
Robin Murphy <robin.murphy(a)arm.com> (3):
arm64: Implement array_index_mask_nospec()
arm64: Make USER_DS an inclusive limit
arm64: Use pointer masking to limit uaccess speculation
Suzuki K Poulose <suzuki.poulose(a)arm.com> (1):
arm64: Run enable method for errata work arounds on late CPUs
Will Deacon <will.deacon(a)arm.com> (14):
arm64: barrier: Add CSDB macros to control data-value prediction
arm64: entry: Ensure branch through syscall table is bounded under speculation
arm64: uaccess: Prevent speculative use of the current addr_limit
arm64: uaccess: Don't bother eliding access_ok checks in __{get, put}_user
arm64: uaccess: Mask __user pointers for __arch_{clear, copy_*}_user
arm64: futex: Mask __user pointers prior to dereference
drivers/firmware: Expose psci_get_version through psci_ops structure
arm64: cpufeature: Pass capability structure to ->enable callback
arm64: Add skeleton to harden the branch predictor against aliasing attacks
arm64: entry: Apply BP hardening for high-priority synchronous exceptions
arm64: entry: Apply BP hardening for suspicious interrupts from EL0
arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75
arm64: Implement branch predictor hardening for affected Cortex-A CPUs
arm64: Add README describing the branch
Yury Norov <ynorov(a)caviumnetworks.com> (1):
arm64: move TASK_* definitions to <asm/processor.h>
proc_sys_link_fill_cache() does not take currently unregistering
sysctl tables into account, which might result into a page fault in
sysctl_follow_link() - add a check to fix it.
This bug has been present since v3.4.
Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between sysctl_table_sets")
Cc: stable(a)vger.kernel.org
Acked-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
---
v2: removed empty line between between sysctl_head_grab and IS_ERR
v3: extend commit message, add tags and cc stable
---
fs/proc/proc_sysctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index c5cbbdff3c3d..82ac5f682b73 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -707,7 +707,10 @@ static bool proc_sys_link_fill_cache(struct file *file,
struct ctl_table *table)
{
bool ret = true;
+
head = sysctl_head_grab(head);
+ if (IS_ERR(head))
+ return false;
if (S_ISLNK(table->mode)) {
/* It is not an error if we can not follow the link ignore it */
--
2.14.1
The following series implements...
Changes since v3 [1]:
* Kill IS_DAX() in favor of explicit IS_FSDAX() and IS_DEVDAX() helpers.
Jan noted, "having IS_DAX() and IS_FSDAX() doing almost the same, just
not exactly the same, is IMHO a recipe for confusion", and I agree. A
nice side effect of this elimination is a cleanup to remove occasions of
"#ifdef CONFIG_FS_DAX" in C files, it is all moved to header files
now. (Jan)
---
The vfio interface, like RDMA, wants to setup long term (indefinite)
pins of the pages backing an address range so that a guest or userspace
driver can perform DMA to the with physical address. Given that this
pinning may lead to filesystem operations deadlocking in the
filesystem-dax case, the pinning request needs to be rejected.
The longer term fix for vfio, RDMA, and any other long term pin user, is
to provide a 'pin with lease' mechanism. Similar to the leases that are
hold for pNFS RDMA layouts, this userspace lease gives the kernel a way
to notify userspace that the block layout of the file is changing and
the kernel is revoking access to pinned pages.
Related to this change is the discovery that vma_is_fsdax() was causing
device-dax inode detection to fail. That lead to series of fixes and
cleanups to make sure that S_DAX is defined correctly in the
CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case.
---
Dan Williams (12):
dax: fix vma_is_fsdax() helper
dax: introduce IS_DEVDAX() and IS_FSDAX()
ext2, dax: finish implementing dax_sem helpers
ext2, dax: define ext2_dax_*() infrastructure in all cases
ext4, dax: define ext4_dax_*() infrastructure in all cases
ext2, dax: replace IS_DAX() with IS_FSDAX()
ext4, dax: replace IS_DAX() with IS_FSDAX()
xfs, dax: replace IS_DAX() with IS_FSDAX()
mm, dax: replace IS_DAX() with IS_DEVDAX() or IS_FSDAX()
fs, dax: kill IS_DAX()
dax: fix S_DAX definition
vfio: disable filesystem-dax page pinning
drivers/vfio/vfio_iommu_type1.c | 18 ++++++++++++++--
fs/ext2/ext2.h | 6 +++++
fs/ext2/file.c | 19 +++++------------
fs/ext2/inode.c | 10 ++++-----
fs/ext4/file.c | 18 +++++-----------
fs/ext4/inode.c | 4 ++--
fs/ext4/ioctl.c | 2 +-
fs/ext4/super.c | 2 +-
fs/iomap.c | 2 +-
fs/xfs/xfs_file.c | 14 ++++++-------
fs/xfs/xfs_ioctl.c | 4 ++--
fs/xfs/xfs_iomap.c | 6 +++--
fs/xfs/xfs_reflink.c | 2 +-
include/linux/dax.h | 12 ++++++++---
include/linux/fs.h | 43 ++++++++++++++++++++++++++++-----------
mm/fadvise.c | 3 ++-
mm/filemap.c | 4 ++--
mm/huge_memory.c | 4 +++-
mm/madvise.c | 3 ++-
19 files changed, 102 insertions(+), 74 deletions(-)
This is the start of the stable review cycle for the 4.15.7 release.
There are 64 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Feb 28 20:21:30 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.7-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.15.7-rc1
Chris Wilson <chris(a)chris-wilson.co.uk>
drm/i915/breadcrumbs: Ignore unsubmitted signalers
Will Deacon <will.deacon(a)arm.com>
arm64: __show_regs: Only resolve kernel symbols when running at EL1
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/amdgpu: add new device to use atpx quirk
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: add atpx quirk handling (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Add dpm quirk for Jet PRO (v2)
Christian König <christian.koenig(a)amd.com>
drm/amdgpu: fix VA hole handling on Vega10 v3
Huang Rui <ray.huang(a)amd.com>
drm/amdgpu: disable MMHUB power gating on raven
Chris Wilson <chris(a)chris-wilson.co.uk>
drm: Handle unexpected holes in color-eviction
Leo (Sunpeng) Li <sunpeng.li(a)amd.com>
drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits
Daniel Vetter <daniel.vetter(a)ffwll.ch>
drm/cirrus: Load lut in crtc_commit
Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Use config_ep_by_speed()
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Process all descriptors during bind
Bin Liu <b-liu(a)ti.com>
Revert "usb: musb: host: don't start next rx urb if current one failed"
Karsten Koop <kkoop(a)ld-didactic.de>
usb: ldusb: add PIDs for new CASSY devices supported by this driver
Fabio Estevam <fabio.estevam(a)nxp.com>
usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: ep0: Reset TRB counter for ep0 IN
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: gadget: Set maxpacket size for ep0 IN
Peter Chen <hzpeterchen(a)gmail.com>
usb: host: ehci: use correct device pointer for dma ops
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
Jack Stocker <jackstocker.93(a)gmail.com>
Add delay-init quirk for Corsair K70 RGB keyboards
Will Deacon <will.deacon(a)arm.com>
arm64: cpufeature: Fix CTR_EL0 field definitions
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Disable unhandled signal log messages by default
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Remove unimplemented syscall log message
AMAN DEEP <aman.deep(a)samsung.com>
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
Mika Westerberg <mika.westerberg(a)linux.intel.com>
net: thunderbolt: Run disconnect flow asynchronously when logout is received
Mika Westerberg <mika.westerberg(a)linux.intel.com>
net: thunderbolt: Tear down connection properly on suspend
Casey Leedom <leedom(a)chelsio.com>
PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
Matt Redfearn <matt.redfearn(a)mips.com>
irqchip/mips-gic: Avoid spuriously handling masked interrupts
Shanker Donthineni <shankerd(a)codeaurora.org>
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
Hauke Mehrtens <hauke(a)hauke-m.de>
uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define
Juergen Gross <jgross(a)suse.com>
mm: don't defer struct page initialization for Xen pv guests
Huang Ying <huang.ying.caritas(a)gmail.com>
mm, swap, frontswap: fix THP swap if frontswap enabled
Arnd Bergmann <arnd(a)arndb.de>
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
Thomas Gleixner <tglx(a)linutronix.de>
x86/apic/vector: Handle vector release on CPU unplug correctly
Arnd Bergmann <arnd(a)arndb.de>
Kbuild: always define endianess in kconfig.h
Lars-Peter Clausen <lars(a)metafoo.de>
iio: adis_lib: Initialize trigger before requesting interrupt
Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
iio: buffer: check if a buffer has been set up when poll is called
Andreas Klinger <ak(a)it-klinger.de>
iio: srf08: fix link error "devm_iio_triggered_buffer_setup" undefined
Fabrice Gasnier <fabrice.gasnier(a)st.com>
iio: adc: stm32: fix stm32h7_adc_enable error handling
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Sanitize user entered port numbers prior to access it
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Fix circular locking dependency
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Fix bad unlock balance in ib_uverbs_close_xrcd
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Protect from command mask overflow
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Protect from races between lookup and destroy of uobjects
Thomas Gleixner <tglx(a)linutronix.de>
genirq/matrix: Handle CPU offlining proper
Hans de Goede <hdegoede(a)redhat.com>
extcon: int3496: process id-pin first so that we start with the right status
Eric Biggers <ebiggers(a)google.com>
PKCS#7: fix certificate blacklisting
Eric Biggers <ebiggers(a)google.com>
PKCS#7: fix certificate chain verification
Eric Biggers <ebiggers(a)google.com>
X.509: fix NULL dereference when restricting key with unsupported_sig
Eric Biggers <ebiggers(a)google.com>
X.509: fix BUG_ON() when hash algorithm is unsupported
Eric Anholt <eric(a)anholt.net>
i2c: bcm2835: Set up the rising/falling edge delays
Ben Gardner <gardner.ben(a)gmail.com>
i2c: designware: must wait for enable
Arnd Bergmann <arnd(a)arndb.de>
cfg80211: fix cfg80211_beacon_dup
James Hogan <jhogan(a)kernel.org>
MIPS: Drop spurious __unused in struct compat_flock
Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix high memory/reserved memory collision
Kees Cook <keescook(a)chromium.org>
MIPS: boot: Define __ASSEMBLY__ for its.S build
Kees Cook <keescook(a)chromium.org>
kconfig.h: Include compiler types to avoid missed struct attributes
Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
arm64: mm: don't write garbage into TTBR1_EL1 register
Paolo Abeni <pabeni(a)redhat.com>
netfilter: drop outermost socket lock in getsockopt()
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/kernel/cpufeature.c | 6 +-
arch/arm64/kernel/process.c | 11 +++-
arch/arm64/kernel/traps.c | 10 +---
arch/arm64/mm/proc.S | 2 +-
arch/mips/boot/Makefile | 1 +
arch/mips/include/asm/compat.h | 1 -
arch/x86/kernel/apic/vector.c | 25 ++++++++-
arch/x86/oprofile/nmi_int.c | 2 +-
arch/xtensa/mm/init.c | 70 +++++++++++++++++++++---
crypto/asymmetric_keys/pkcs7_verify.c | 12 ++--
crypto/asymmetric_keys/public_key.c | 4 +-
crypto/asymmetric_keys/restrict.c | 21 ++++---
drivers/extcon/extcon-intel-int3496.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 58 +++++++++++++++++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 10 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 11 ++++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 13 +++++
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 ++
drivers/gpu/drm/amd/amdgpu/soc15.c | 4 +-
drivers/gpu/drm/amd/amdgpu/vi.c | 21 ++++---
drivers/gpu/drm/cirrus/cirrus_mode.c | 40 ++++++++------
drivers/gpu/drm/drm_atomic_helper.c | 15 +++++
drivers/gpu/drm/drm_edid.c | 3 +
drivers/gpu/drm/drm_mm.c | 21 ++++++-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 29 ++++------
drivers/hid/hid-core.c | 3 +
drivers/hid/hid-ids.h | 3 +
drivers/i2c/busses/i2c-bcm2835.c | 21 ++++++-
drivers/i2c/busses/i2c-designware-master.c | 2 +-
drivers/iio/adc/stm32-adc.c | 7 ++-
drivers/iio/imu/adis_trigger.c | 7 ++-
drivers/iio/industrialio-buffer.c | 2 +-
drivers/iio/proximity/Kconfig | 2 +
drivers/infiniband/core/rdma_core.c | 10 +++-
drivers/infiniband/core/uverbs_cmd.c | 16 ++++--
drivers/infiniband/core/uverbs_main.c | 27 ++++++---
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/irqchip/irq-mips-gic.c | 2 -
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 ----
drivers/net/thunderbolt.c | 19 +++++--
drivers/pci/quirks.c | 39 +++++++------
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
drivers/usb/core/quirks.c | 3 +
drivers/usb/dwc3/ep0.c | 7 ++-
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/gadget/function/f_fs.c | 44 +++------------
drivers/usb/host/ehci-hub.c | 4 +-
drivers/usb/host/ohci-hcd.c | 10 +++-
drivers/usb/host/ohci-hub.c | 4 +-
drivers/usb/host/ohci-q.c | 17 +++---
drivers/usb/misc/ldusb.c | 6 ++
drivers/usb/musb/musb_host.c | 8 +--
drivers/usb/phy/phy-mxs-usb.c | 3 +
drivers/usb/renesas_usbhs/fifo.c | 5 ++
drivers/xen/tmem.c | 4 ++
include/drm/drm_atomic.h | 9 +++
include/linux/kconfig.h | 9 +++
include/uapi/linux/if_ether.h | 6 +-
include/uapi/linux/libc-compat.h | 6 --
kernel/irq/matrix.c | 23 +++++---
mm/page_alloc.c | 4 ++
mm/zswap.c | 6 ++
net/ipv4/ip_sockglue.c | 7 +--
net/ipv6/ipv6_sockglue.c | 10 +---
net/mac80211/cfg.c | 2 +-
68 files changed, 530 insertions(+), 251 deletions(-)
This is a note to let you know that I've just added the patch titled
microblaze: fix endian handling
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
microblaze-fix-endian-handling.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 2 Jan 2018 12:47:19 +0100
Subject: microblaze: fix endian handling
From: Arnd Bergmann <arnd(a)arndb.de>
commit 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f upstream.
Building an allmodconfig kernel fails horribly because of
endian mismatch. It turns out that the -mlittle-endian
switch was not honored at all as we were using the wrong
Kconfig symbol and failing to apply CPUFLAGS to the CFLAGS.
Finally, the linker flags did not get set right.
This addresses all three of those issues, which now lets
me build both big-endian and little-endian kernels for
testing.
Fixes: 428dbf156cc5 ("arch: change default endian for microblaze")
Fixes: 206d3642d8ee ("arch/microblaze: add choice for endianness and update Makefile")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Michal Simek <michal.simek(a)xilinx.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/microblaze/Makefile | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -36,16 +36,21 @@ endif
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
-CPUFLAGS-$(CONFIG_BIG_ENDIAN) += -mbig-endian
-CPUFLAGS-$(CONFIG_LITTLE_ENDIAN) += -mlittle-endian
+
+ifdef CONFIG_CPU_BIG_ENDIAN
+KBUILD_CFLAGS += -mbig-endian
+KBUILD_AFLAGS += -mbig-endian
+LD += -EB
+else
+KBUILD_CFLAGS += -mlittle-endian
+KBUILD_AFLAGS += -mlittle-endian
+LD += -EL
+endif
CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
# r31 holds current when in kernel mode
-KBUILD_CFLAGS += -ffixed-r31 $(CPUFLAGS-1) $(CPUFLAGS-2)
-
-LDFLAGS :=
-LDFLAGS_vmlinux :=
+KBUILD_CFLAGS += -ffixed-r31 $(CPUFLAGS-y) $(CPUFLAGS-1) $(CPUFLAGS-2)
head-y := arch/microblaze/kernel/head.o
libs-y += arch/microblaze/lib/
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/microblaze-fix-endian-handling.patch
queue-4.15/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.15/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.15/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
microblaze: fix endian 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:
microblaze-fix-endian-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 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 2 Jan 2018 12:47:19 +0100
Subject: microblaze: fix endian handling
From: Arnd Bergmann <arnd(a)arndb.de>
commit 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f upstream.
Building an allmodconfig kernel fails horribly because of
endian mismatch. It turns out that the -mlittle-endian
switch was not honored at all as we were using the wrong
Kconfig symbol and failing to apply CPUFLAGS to the CFLAGS.
Finally, the linker flags did not get set right.
This addresses all three of those issues, which now lets
me build both big-endian and little-endian kernels for
testing.
Fixes: 428dbf156cc5 ("arch: change default endian for microblaze")
Fixes: 206d3642d8ee ("arch/microblaze: add choice for endianness and update Makefile")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Michal Simek <michal.simek(a)xilinx.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/microblaze/Makefile | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -36,16 +36,21 @@ endif
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
-CPUFLAGS-$(CONFIG_BIG_ENDIAN) += -mbig-endian
-CPUFLAGS-$(CONFIG_LITTLE_ENDIAN) += -mlittle-endian
+
+ifdef CONFIG_CPU_BIG_ENDIAN
+KBUILD_CFLAGS += -mbig-endian
+KBUILD_AFLAGS += -mbig-endian
+LD += -EB
+else
+KBUILD_CFLAGS += -mlittle-endian
+KBUILD_AFLAGS += -mlittle-endian
+LD += -EL
+endif
CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
# r31 holds current when in kernel mode
-KBUILD_CFLAGS += -ffixed-r31 $(CPUFLAGS-1) $(CPUFLAGS-2)
-
-LDFLAGS :=
-LDFLAGS_vmlinux :=
+KBUILD_CFLAGS += -ffixed-r31 $(CPUFLAGS-y) $(CPUFLAGS-1) $(CPUFLAGS-2)
head-y := arch/microblaze/kernel/head.o
libs-y += arch/microblaze/lib/
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/microblaze-fix-endian-handling.patch
queue-4.14/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.14/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.14/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
m32r: fix endianness constraints
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:
m32r-fix-endianness-constraints.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 c95f121142a41c951fd62683a5574f2a7b37c573 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Wed, 15 Nov 2017 17:31:18 -0800
Subject: m32r: fix endianness constraints
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
commit c95f121142a41c951fd62683a5574f2a7b37c573 upstream.
The m32r Kconfig provides both CPU_BIG_ENDIAN and CPU_LITTLE_ENDIAN
configuration options. As they are user-selectable and independent,
this allows invalid configurations:
- All m32r defconfigs build a big endian kernel, but CPU_BIG_ENDIAN is
not set, causing compiler warnings like:
include/linux/byteorder/big_endian.h:7:2: warning: #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
#warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
^
- Since commit 5bdfca6435b82944 ("m32r: define CPU_BIG_ENDIAN"),
building an allmodconfig or allyesconfig enables both
CONFIG_CPU_BIG_ENDIAN and CONFIG_CPU_LITTLE_ENDIAN.
While this did get rid of the warning above, both options are
obviously mutually exclusive.
Fix this by making only CPU_LITTLE_ENDIAN configurable by the user, as
before, and by making sure exactly one of CPU_BIG_ENDIAN and
CPU_LITTLE_ENDIAN is always enabled.
Link: http://lkml.kernel.org/r/1509361505-18150-1-git-send-email-geert@linux-m68k…
Fixes: 5bdfca6435b82944 ("m32r: define CPU_BIG_ENDIAN")
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Cc: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/m32r/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -196,8 +196,8 @@ config TIMER_DIVIDE
default "128"
config CPU_BIG_ENDIAN
- bool "Generate big endian code"
- default n
+ bool
+ default !CPU_LITTLE_ENDIAN
config CPU_LITTLE_ENDIAN
bool "Generate little endian code"
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.14/m32r-fix-endianness-constraints.patch
This is the start of the stable review cycle for the 4.9.85 release.
There are 39 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Feb 28 20:16:31 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.85-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.85-rc1
Dan Williams <dan.j.williams(a)intel.com>
x86/entry/64: Clear extra registers beyond syscall arguments, to reduce speculation attack surface
Dan Williams <dan.j.williams(a)intel.com>
mm: fail get_vaddr_frames() for filesystem-dax mappings
Jan H. Schönherr <jschoenh(a)amazon.de>
mm: Fix devm_memremap_pages() collision handling
Dan Williams <dan.j.williams(a)intel.com>
libnvdimm, dax: fix 1GB-aligned namespaces vs physical misalignment
Dan Williams <dan.j.williams(a)intel.com>
IB/core: disable memory registration of filesystem-dax vmas
Dan Williams <dan.j.williams(a)intel.com>
v4l2: disable filesystem-dax mapping support
Dan Williams <dan.j.williams(a)intel.com>
mm: introduce get_user_pages_longterm
Dan Williams <dan.j.williams(a)intel.com>
device-dax: implement ->split() to catch invalid munmap attempts
Dan Williams <dan.j.williams(a)intel.com>
libnvdimm: fix integer overflow static analysis warning
Jan Kara <jack(a)suse.cz>
fs/dax.c: fix inefficiency in dax_writeback_mapping_range()
Ross Zwisler <ross.zwisler(a)linux.intel.com>
mm: avoid spurious 'bad pmd' warning messages
Eric Biggers <ebiggers(a)google.com>
X.509: fix NULL dereference when restricting key with unsupported_sig
Eric Biggers <ebiggers(a)google.com>
binder: add missing binder_unlock()
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/amdgpu: add new device to use atpx quirk
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: add atpx quirk handling (v2)
Alex Deucher <alexander.deucher(a)amd.com>
drm/amdgpu: Add dpm quirk for Jet PRO (v2)
Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Process all descriptors during bind
Bin Liu <b-liu(a)ti.com>
Revert "usb: musb: host: don't start next rx urb if current one failed"
Karsten Koop <kkoop(a)ld-didactic.de>
usb: ldusb: add PIDs for new CASSY devices supported by this driver
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: gadget: Set maxpacket size for ep0 IN
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
Jack Stocker <jackstocker.93(a)gmail.com>
Add delay-init quirk for Corsair K70 RGB keyboards
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Disable unhandled signal log messages by default
AMAN DEEP <aman.deep(a)samsung.com>
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
Shigeru Yoshida <shigeru.yoshida(a)windriver.com>
ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
Casey Leedom <leedom(a)chelsio.com>
PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
Shanker Donthineni <shankerd(a)codeaurora.org>
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
Arnd Bergmann <arnd(a)arndb.de>
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
Lars-Peter Clausen <lars(a)metafoo.de>
iio: adis_lib: Initialize trigger before requesting interrupt
Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
iio: buffer: check if a buffer has been set up when poll is called
Leon Romanovsky <leonro(a)mellanox.com>
RDMA/uverbs: Protect from command mask overflow
Eric Biggers <ebiggers(a)google.com>
PKCS#7: fix certificate chain verification
Eric Biggers <ebiggers(a)google.com>
X.509: fix BUG_ON() when hash algorithm is unsupported
Arnd Bergmann <arnd(a)arndb.de>
cfg80211: fix cfg80211_beacon_dup
Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix high memory/reserved memory collision
Paolo Abeni <pabeni(a)redhat.com>
netfilter: drop outermost socket lock in getsockopt()
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/kernel/traps.c | 2 +-
arch/x86/entry/entry_64.S | 13 +++++
arch/x86/oprofile/nmi_int.c | 2 +-
arch/xtensa/mm/init.c | 70 +++++++++++++++++++++---
crypto/asymmetric_keys/pkcs7_verify.c | 2 +-
crypto/asymmetric_keys/public_key.c | 4 +-
crypto/asymmetric_keys/restrict.c | 7 ++-
drivers/android/binder.c | 4 +-
drivers/dax/dax.c | 12 ++++
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 58 +++++++++++++++++---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 ++
drivers/gpu/drm/drm_edid.c | 3 +
drivers/hid/hid-core.c | 3 +
drivers/hid/hid-ids.h | 3 +
drivers/iio/imu/adis_trigger.c | 7 ++-
drivers/iio/industrialio-buffer.c | 2 +-
drivers/infiniband/core/umem.c | 2 +-
drivers/infiniband/core/uverbs_main.c | 27 ++++++---
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/media/v4l2-core/videobuf-dma-sg.c | 5 +-
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 ----
drivers/nvdimm/bus.c | 11 ++--
drivers/nvdimm/pfn_devs.c | 15 ++++-
drivers/pci/quirks.c | 39 +++++++------
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
drivers/usb/core/quirks.c | 3 +
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/gadget/function/f_fs.c | 6 +-
drivers/usb/host/ohci-hcd.c | 10 +++-
drivers/usb/host/ohci-hub.c | 4 +-
drivers/usb/host/ohci-q.c | 17 +++---
drivers/usb/misc/ldusb.c | 6 ++
drivers/usb/musb/musb_host.c | 8 +--
drivers/usb/renesas_usbhs/fifo.c | 5 ++
fs/dax.c | 1 +
include/linux/dax.h | 5 --
include/linux/fs.h | 20 +++++++
include/linux/kernel.h | 1 +
include/linux/mm.h | 13 +++++
kernel/memremap.c | 13 +++--
mm/frame_vector.c | 12 ++++
mm/gup.c | 64 ++++++++++++++++++++++
mm/memory.c | 40 ++++++++++----
net/ipv4/ip_sockglue.c | 7 +--
net/ipv6/ipv6_sockglue.c | 10 +---
net/mac80211/cfg.c | 2 +-
48 files changed, 433 insertions(+), 132 deletions(-)
This is the start of the stable review cycle for the 3.18.97 release.
There are 13 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Feb 28 20:15:12 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.97-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.97-rc1
Eric Biggers <ebiggers(a)google.com>
ASN.1: fix out-of-bounds read when parsing indefinite length item
Jack Pham <jackp(a)codeaurora.org>
usb: gadget: f_fs: Process all descriptors during bind
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: gadget: Set maxpacket size for ep0 IN
Michael Weiser <michael.weiser(a)gmx.de>
arm64: Disable unhandled signal log messages by default
Shanker Donthineni <shankerd(a)codeaurora.org>
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
Arnd Bergmann <arnd(a)arndb.de>
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
Lars-Peter Clausen <lars(a)metafoo.de>
iio: adis_lib: Initialize trigger before requesting interrupt
Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
iio: buffer: check if a buffer has been set up when poll is called
Arnd Bergmann <arnd(a)arndb.de>
cfg80211: fix cfg80211_beacon_dup
Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix high memory/reserved memory collision
Johan Hovold <johan(a)kernel.org>
PCI: keystone: Fix interrupt-controller-node lookup
Paolo Abeni <pabeni(a)redhat.com>
netfilter: drop outermost socket lock in getsockopt()
-------------
Diffstat:
Makefile | 4 +--
arch/arm64/kernel/traps.c | 2 +-
arch/x86/oprofile/nmi_int.c | 2 +-
arch/xtensa/mm/init.c | 70 ++++++++++++++++++++++++++++++++++----
drivers/iio/imu/adis_trigger.c | 7 ++--
drivers/iio/industrialio-buffer.c | 2 +-
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/pci/host/pci-keystone.c | 9 +++--
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
drivers/usb/dwc3/gadget.c | 2 ++
drivers/usb/gadget/function/f_fs.c | 6 ++--
lib/asn1_decoder.c | 43 ++++++++++++-----------
net/ipv4/ip_sockglue.c | 7 +---
net/ipv6/ipv6_sockglue.c | 10 ++----
net/mac80211/cfg.c | 2 +-
15 files changed, 113 insertions(+), 57 deletions(-)
When an MSI descriptor was not available, the error path would try to
unbind an irq that was never acquired - potentially unbinding an
unrelated irq.
Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
Reported-by: Hooman Mirhadi <mirhadih(a)amazon.com>
CC: <stable(a)vger.kernel.org>
CC: Roger Pau Monné <roger.pau(a)citrix.com>
CC: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
CC: Eduardo Valentin <eduval(a)amazon.com>
CC: Juergen Gross <jgross(a)suse.com>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: "K. Y. Srinivasan" <kys(a)microsoft.com>
CC: Liu Shuo <shuo.a.liu(a)intel.com>
CC: Anoob Soman <anoob.soman(a)citrix.com>
Signed-off-by: Amit Shah <aams(a)amazon.com>
---
drivers/xen/events/events_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 1ab4bd1..c86d10e 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -755,8 +755,10 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
mutex_unlock(&irq_mapping_update_lock);
return irq;
error_irq:
- for (; i >= 0; i--)
+ while (i > 0) {
+ i--;
__unbind_from_irq(irq + i);
+ }
mutex_unlock(&irq_mapping_update_lock);
return ret;
}
--
2.7.3.AMZN
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
tmu_read() in case of Exynos4210 might return error for out of bound
values. Current code ignores such value, what leads to reporting critical
temperature value. Add proper error code propagation to exynos_get_temp()
function.
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
CC: stable(a)vger.kernel.org # v4.6+
---
This patch is prepared on top of "thermal: exynos: Reading temperature
makes sense only when TMU is turned on" patch. Both are required
to finally fix thermal support on Exynos4210 based boards.
This patch only applies cleanly together with the mentioned "thermal:
exynos: Reading temperature makes sense only when TMU is turned on"
patch on v4.6+ kernels.
---
drivers/thermal/samsung/exynos_tmu.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 986cbd01aaaa..74adeb1d2daf 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -892,6 +892,7 @@ static void exynos7_tmu_control(struct platform_device *pdev, bool on)
static int exynos_get_temp(void *p, int *temp)
{
struct exynos_tmu_data *data = p;
+ int value, ret = 0;
if (!data || !data->tmu_read || !data->enabled)
return -EINVAL;
@@ -899,12 +900,16 @@ static int exynos_get_temp(void *p, int *temp)
mutex_lock(&data->lock);
clk_enable(data->clk);
- *temp = code_to_temp(data, data->tmu_read(data)) * MCELSIUS;
+ value = data->tmu_read(data);
+ if (value < 0)
+ ret = value;
+ else
+ *temp = code_to_temp(data, value) * MCELSIUS;
clk_disable(data->clk);
mutex_unlock(&data->lock);
- return 0;
+ return ret;
}
#ifdef CONFIG_THERMAL_EMULATION
--
2.15.0
On 2/27/18 2:38 AM, Mark Brown wrote:
> On Mon, Feb 26, 2018 at 06:30:15PM -0800, Pierre-Louis Bossart wrote:
>> On 2/26/18 10:34 AM, Kirill Marinushkin wrote:
>
>>> According to the comment, the existing functionality works correctly "WRT the
>>> interface". The suggested commit doesn't fix the behaviour: instead, it reverts
>>> the logic to "WRT the codec". But the existing implementation is also valid.
>
>> Look at all the machine drivers, they always use the mask by looking at the
>> codec side. The comment on top means that the SOC side ('the interface') is
>> the dual of the codec side.
>
>> This issue was found during the development of SOF (Sound Open Firmware)
>> where we get the reverse of the intended behavior when using the same
>> conventions in topology files as in machine drivers.
>
> Is this perhaps something that the earlier firmware is handling inside
> the firmware?
For SKL+ the SSP settings come from binary blobs read from ACPI/NHLT
tables so I am wondering if this inversion is compensated for in the
tools used to generate the blobs.
When thermal sensor is not yet enabled, reading temperature might return
random value. This might even result in stopping system booting when such
temperature is higher than the critical value. Fix this by checking if TMU
has been actually enabled before reading the temperature.
This change fixes booting of Exynos4210-based board with TMU enabled (for
example Samsung Trats board), which was broken since v4.4 kernel release.
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Fixes: 9e4249b40340 ("thermal: exynos: Fix first temperature read after registering sensor")
CC: stable(a)vger.kernel.org # v4.6+
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
---
This issue is there since commit 9e4249b40340 ("thermal: exynos: Fix
first temperature read after registering sensor"), but this patch applies
cleanly only to v4.6+ kernels.
---
drivers/thermal/samsung/exynos_tmu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index ed805c7c5ace..986cbd01aaaa 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -185,6 +185,7 @@
* @regulator: pointer to the TMU regulator structure.
* @reg_conf: pointer to structure to register with core thermal.
* @ntrip: number of supported trip points.
+ * @enabled: current status of TMU device
* @tmu_initialize: SoC specific TMU initialization method
* @tmu_control: SoC specific TMU control method
* @tmu_read: SoC specific TMU temperature read method
@@ -205,6 +206,7 @@ struct exynos_tmu_data {
struct regulator *regulator;
struct thermal_zone_device *tzd;
unsigned int ntrip;
+ bool enabled;
int (*tmu_initialize)(struct platform_device *pdev);
void (*tmu_control)(struct platform_device *pdev, bool on);
@@ -398,6 +400,7 @@ static void exynos_tmu_control(struct platform_device *pdev, bool on)
mutex_lock(&data->lock);
clk_enable(data->clk);
data->tmu_control(pdev, on);
+ data->enabled = on;
clk_disable(data->clk);
mutex_unlock(&data->lock);
}
@@ -890,7 +893,7 @@ static int exynos_get_temp(void *p, int *temp)
{
struct exynos_tmu_data *data = p;
- if (!data || !data->tmu_read)
+ if (!data || !data->tmu_read || !data->enabled)
return -EINVAL;
mutex_lock(&data->lock);
--
2.15.0
On Tue, Feb 27, 2018 at 02:17:15AM +0000, Harsh Shandilya wrote:
> On Tue 27 Feb, 2018, 1:47 AM Greg Kroah-Hartman, <gregkh(a)linuxfoundation.org>
> wrote:
>
> > This is the start of the stable review cycle for the 3.18.97 release.
> > There are 13 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Feb 28 20:15:12 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.97-rc…
> > or in the git tree and branch at:
> > git://
> > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > linux-3.18.y
> > and the diffstat can be found below.
> >
>
> No regressions noticed on the OnePlus 3T. CAF's msm-3.18 tree requires
> reverting commit
> https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit?id=1278f001ef9…
> to avoid conflicting with the patch titled "usb: gadget: f_fs: Process all
> descriptors during bind", kernel-common has no merge problems. Thanks for
> the update.
Thanks for testing this and letting me know.
greg k-h
From: Ben Gardner <gardner.ben(a)gmail.com>
commit fba4adbbf670577e605f9ad306629db6031cd48b upstream.
One I2C bus on my Atom E3845 board has been broken since 4.9.
It has two devices, both declared by ACPI and with built-in drivers.
There are two back-to-back transactions originating from the kernel, one
targeting each device. The first transaction works, the second one locks
up the I2C controller. The controller never recovers.
These kernel logs show up whenever an I2C transaction is attempted after
this failure.
i2c-designware-pci 0000:00:18.3: timeout in disabling adapter
i2c-designware-pci 0000:00:18.3: timeout waiting for bus ready
Waiting for the I2C controller status to indicate that it is enabled
before programming it fixes the issue.
I have tested this patch on 4.14 and 4.15.
Fixes: commit 2702ea7dbec5 ("i2c: designware: wait for disable/enable only if necessary")
Cc: linux-stable <stable(a)vger.kernel.org> # v4.9..v4.12
Signed-off-by: Ben Gardner <gardner.ben(a)gmail.com>
[Jarkko: Backported to v4.9..v4.12 before i2c-designware-core.c was
renamed to i2c-designware-master.c]
Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
---
drivers/i2c/busses/i2c-designware-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 809f4d4e93a0..340e037b3224 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -507,7 +507,7 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
i2c_dw_disable_int(dev);
/* Enable the adapter */
- __i2c_dw_enable(dev, true);
+ __i2c_dw_enable_and_wait(dev, true);
/* Clear and enable interrupts */
dw_readl(dev, DW_IC_CLR_INTR);
--
2.16.1
To reproduce the lock up do the following
- connect otg host adapter and a USB device to the dual-role port
so that it is in host mode.
- suspend to mem.
- disconnect otg adapter.
- resume the system.
If we call dwc3_host_exit() before tasks are thawed
xhci_plat_remove() seems to lock up at the second usb_remove_hcd() call.
To work around this we queue the _dwc3_set_mode() work on
the system_freezable_wq.
Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly")
Cc: <stable(a)vger.kernel.org> # v4.12+
Suggested-by: Manu Gautam <mgautam(a)codeaurora.org>
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
---
drivers/usb/dwc3/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index f1d838a..e94bf91 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -175,7 +175,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
dwc->desired_dr_role = mode;
spin_unlock_irqrestore(&dwc->lock, flags);
- queue_work(system_power_efficient_wq, &dwc->drd_work);
+ queue_work(system_freezable_wq, &dwc->drd_work);
}
u32 dwc3_core_fifo_space(struct dwc3_ep *dep, u8 type)
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Due to using gcc defines for configuration, some labels might be unused in
certain configurations. While adding a __maybe_unused to the label is
fine in general, the line has to be terminated with ';'. This is also
reflected in the gcc documentation, but gcc parsed the previous variant
without an error message.
This has been spotted while compiling with goto-cc, the compiler for the
CPROVER tool suite.
Signed-off-by: Norbert Manthey <nmanthey(a)amazon.de>
Signed-off-by: Michael Tautschnig <tautschn(a)amazon.co.uk>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 26a71eb..3af8fb6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6716,7 +6716,7 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf
p = task_of(se);
-done: __maybe_unused
+done: __maybe_unused;
#ifdef CONFIG_SMP
/*
* Move the next running task to the front of
--
2.7.4
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
The patch
ASoC: topology: Fix logical inversion in set_link_hw_format()
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7f34c3f38e9666216fda155b6ebededd1073f5aa Mon Sep 17 00:00:00 2001
From: Pan Xiuli <xiuli.pan(a)linux.intel.com>
Date: Fri, 23 Feb 2018 06:01:28 +0800
Subject: [PATCH] ASoC: topology: Fix logical inversion in set_link_hw_format()
The master/slave conventions are wrt. the codec. The topology code
contains a logical inversion, fix to follow ASoC usage.
Signed-off-by: Pan Xiuli <xiuli.pan(a)linux.intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/soc-topology.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c
index 01a50413c66f..5f507993c43e 100644
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -1996,11 +1996,11 @@ static void set_link_hw_format(struct snd_soc_dai_link *link,
/* clock masters */
bclk_master = hw_config->bclk_master;
fsync_master = hw_config->fsync_master;
- if (!bclk_master && !fsync_master)
+ if (bclk_master && fsync_master)
link->dai_fmt |= SND_SOC_DAIFMT_CBM_CFM;
- else if (bclk_master && !fsync_master)
- link->dai_fmt |= SND_SOC_DAIFMT_CBS_CFM;
else if (!bclk_master && fsync_master)
+ link->dai_fmt |= SND_SOC_DAIFMT_CBS_CFM;
+ else if (bclk_master && !fsync_master)
link->dai_fmt |= SND_SOC_DAIFMT_CBM_CFS;
else
link->dai_fmt |= SND_SOC_DAIFMT_CBS_CFS;
--
2.16.1
On 02/26/18 20:47, Mark Brown wrote:
> On Mon, Feb 26, 2018 at 07:34:07PM +0100, Kirill Marinushkin wrote:
>
>> 2. The suggested commit breaks the existing ASoC.
>> The existing functionality already works with several existing ASoC by
>> Intel. The suggested commit will break it for the following reason:
>> The ALSA topology mechanism loads the binary topology file into ASoC. The
>> suggested commit modifies the parser, but the binaries are already created for
>> the existing functionality. As a result, all existing binaries will be parsed
>> incorrectly.
> Are there actual binaries using the existing code or is that just
> theoretical? My impression was that this was fixing things for existing
> binaries which were shipped for non-mainline kernels, is that not the
> case?
There is an actual conf, which can be converted into an actual binary:
`alsa-lib/src/conf/topology/broadwell/broadwell.conf`
Theoretically, there can be an unknown number of the binaries, not available publicly.
Broadwell exists for a long time, and there is no way to be sure that all the theoretically
existing binaries are modified together with this kernel patch.
On Mon, 2018-02-12 at 08:24 +0100, Paolo Valente wrote:
>
> > Il giorno 10 feb 2018, alle ore 09:29, Oleksandr Natalenko <oleksandr(a)natalenko.name> ha scritto:
> >
> > Hi.
> >
> > On pátek 9. února 2018 18:29:39 CET Mike Galbraith wrote:
> >> On Fri, 2018-02-09 at 14:21 +0100, Oleksandr Natalenko wrote:
> >>> In addition to this I think it should be worth considering CC'ing Greg
> >>> to pull this fix into 4.15 stable tree.
> >>
> >> This isn't one he can cherry-pick, some munging required, in which case
> >> he usually wants a properly tested backport.
> >>
> >> -Mike
> >
> > Maybe, this could be a good opportunity to push all the pending BFQ patches
> > into the stable 4.15 branch? Because IIUC currently BFQ in 4.15 is just
> > unusable.
> >
> > Paolo?
> >
>
> Of course ok for me, and thanks Oleksandr for proposing this. These
> commits should apply cleanly on 4.15, and FWIW have been tested, by me
> and BFQ users, on 4.15 too in these months.
How does that work without someone actually submitting patches? CC
stable and pass along a conveniently sorted cherry-pick list?
9b25bd0368d5 block, bfq: remove batches of confusing ifdefs
a34b024448eb block, bfq: consider also past I/O in soft real-time detection
4403e4e467c3 block, bfq: remove superfluous check in queue-merging setup
7b8fa3b900a0 block, bfq: let a queue be merged only shortly after starting I/O
1be6e8a964ee block, bfq: check low_latency flag in bfq_bfqq_save_state()
05e902835616 block, bfq: add missing rq_pos_tree update on rq removal
f0ba5ea2fe45 block, bfq: increase threshold to deem I/O as random
0d52af590552 block, bfq: release oom-queue ref to root group on exit
52257ffbfcaf block, bfq: put async queues for root bfq groups too
8abef10b3de1 bfq-iosched: don't call bfqg_and_blkg_put for !CONFIG_BFQ_GROUP_IOSCHED
8993d445df38 block, bfq: fix occurrences of request finish method's old name
8a8747dc01ce block, bfq: limit sectors served with interactive weight raising
a52a69ea89dc block, bfq: limit tags for writes and async I/O
a78773906147 block, bfq: add requeue-request hook
> ---
> >
> > block, bfq: add requeue-request hook
> > bfq-iosched: don't call bfqg_and_blkg_put for !CONFIG_BFQ_GROUP_IOSCHED
> > block, bfq: release oom-queue ref to root group on exit
> > block, bfq: put async queues for root bfq groups too
> > block, bfq: limit sectors served with interactive weight raising
> > block, bfq: limit tags for writes and async I/O
> > block, bfq: increase threshold to deem I/O as random
> > block, bfq: remove superfluous check in queue-merging setup
> > block, bfq: let a queue be merged only shortly after starting I/O
> > block, bfq: check low_latency flag in bfq_bfqq_save_state()
> > block, bfq: add missing rq_pos_tree update on rq removal
> > block, bfq: fix occurrences of request finish method's old name
> > block, bfq: consider also past I/O in soft real-time detection
> > block, bfq: remove batches of confusing ifdefs
> >
> >
>
When an MSI descriptor was not available, the error path would try to
unbind an irq that was never acquired - potentially unbinding an
unrelated irq.
Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
Reported-by: Hooman Mirhadi <mirhadih(a)amazon.com>
CC: <stable(a)vger.kernel.org>
CC: Roger Pau Monné <roger.pau(a)citrix.com>
CC: David Vrabel <david.vrabel(a)citrix.com>
CC: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
CC: Eduardo Valentin <eduval(a)amazon.com>
CC: Juergen Gross <jgross(a)suse.com>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: "K. Y. Srinivasan" <kys(a)microsoft.com>
CC: Liu Shuo <shuo.a.liu(a)intel.com>
CC: Anoob Soman <anoob.soman(a)citrix.com>
Signed-off-by: Amit Shah <aams(a)amazon.com>
---
drivers/xen/events/events_base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 1ab4bd1..b6b8b29 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -749,6 +749,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
}
ret = irq_set_msi_desc(irq, msidesc);
+ i--;
if (ret < 0)
goto error_irq;
out:
--
2.7.3.AMZN
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
commit 8e1eb3fa009aa7c0b944b3c8b26b07de0efb3200 upstream.
At entry userspace may have (maliciously) populated the extra registers
outside the syscall calling convention with arbitrary values that could
be useful in a speculative execution (Spectre style) attack.
Clear these registers to minimize the kernel's attack surface.
Note, this only clears the extra registers and not the unused
registers for syscalls less than 6 arguments, since those registers are
likely to be clobbered well before their values could be put to use
under speculation.
Note, Linus found that the XOR instructions can be executed with
minimized cost if interleaved with the PUSH instructions, and Ingo's
analysis found that R10 and R11 should be included in the register
clearing beyond the typical 'extra' syscall calling convention
registers.
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Reported-by: Andi Kleen <ak(a)linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/151787988577.7847.16733592218894189003.stgit@dwill…
[ Made small improvements to the changelog and the code comments. ]
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
---
arch/x86/entry/entry_64.S | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index db5009ce065a..8d7e4d48db0d 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -176,13 +176,26 @@ GLOBAL(entry_SYSCALL_64_after_swapgs)
pushq %r8 /* pt_regs->r8 */
pushq %r9 /* pt_regs->r9 */
pushq %r10 /* pt_regs->r10 */
+ /*
+ * Clear extra registers that a speculation attack might
+ * otherwise want to exploit. Interleave XOR with PUSH
+ * for better uop scheduling:
+ */
+ xorq %r10, %r10 /* nospec r10 */
pushq %r11 /* pt_regs->r11 */
+ xorq %r11, %r11 /* nospec r11 */
pushq %rbx /* pt_regs->rbx */
+ xorl %ebx, %ebx /* nospec rbx */
pushq %rbp /* pt_regs->rbp */
+ xorl %ebp, %ebp /* nospec rbp */
pushq %r12 /* pt_regs->r12 */
+ xorq %r12, %r12 /* nospec r12 */
pushq %r13 /* pt_regs->r13 */
+ xorq %r13, %r13 /* nospec r13 */
pushq %r14 /* pt_regs->r14 */
+ xorq %r14, %r14 /* nospec r14 */
pushq %r15 /* pt_regs->r15 */
+ xorq %r15, %r15 /* nospec r15 */
/* IRQs are off. */
movq %rsp, %rdi
commit b70131de648c2b997d22f4653934438013f407a1 upstream.
V4L2 memory registrations are incompatible with filesystem-dax that
needs the ability to revoke dma access to a mapping at will, or
otherwise allow the kernel to wait for completion of DMA. The
filesystem-dax implementation breaks the traditional solution of
truncate of active file backed mappings since there is no page-cache
page we can orphan to sustain ongoing DMA.
If v4l2 wants to support long lived DMA mappings it needs to arrange to
hold a file lease or use some other mechanism so that the kernel can
coordinate revoking DMA access when the filesystem needs to truncate
mappings.
Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwill…
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Reported-by: Jan Kara <jack(a)suse.cz>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Doug Ledford <dledford(a)redhat.com>
Cc: Hal Rosenstock <hal.rosenstock(a)gmail.com>
Cc: Inki Dae <inki.dae(a)samsung.com>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Jeff Moyer <jmoyer(a)redhat.com>
Cc: Joonyoung Shim <jy0922.shim(a)samsung.com>
Cc: Kyungmin Park <kyungmin.park(a)samsung.com>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Cc: Sean Hefty <sean.hefty(a)intel.com>
Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
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>
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 1db0af6c7f94..b6189a4958c5 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -185,12 +185,13 @@ static int videobuf_dma_init_user_locked(struct videobuf_dmabuf *dma,
dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
data, size, dma->nr_pages);
- err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
+ err = get_user_pages_longterm(data & PAGE_MASK, dma->nr_pages,
flags, dma->pages, NULL);
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
- dprintk(1, "get_user_pages: err=%d [%d]\n", err, dma->nr_pages);
+ dprintk(1, "get_user_pages_longterm: err=%d [%d]\n", err,
+ dma->nr_pages);
return err < 0 ? err : -EINVAL;
}
return 0;
commit 2bb6d2837083de722bfdc369cb0d76ce188dd9b4 upstream.
Patch series "introduce get_user_pages_longterm()", v2.
Here is a new get_user_pages api for cases where a driver intends to
keep an elevated page count indefinitely. This is distinct from usages
like iov_iter_get_pages where the elevated page counts are transient.
The iov_iter_get_pages cases immediately turn around and submit the
pages to a device driver which will put_page when the i/o operation
completes (under kernel control).
In the longterm case userspace is responsible for dropping the page
reference at some undefined point in the future. This is untenable for
filesystem-dax case where the filesystem is in control of the lifetime
of the block / page and needs reasonable limits on how long it can wait
for pages in a mapping to become idle.
Fixing filesystems to actually wait for dax pages to be idle before
blocks from a truncate/hole-punch operation are repurposed is saved for
a later patch series.
Also, allowing longterm registration of dax mappings is a future patch
series that introduces a "map with lease" semantic where the kernel can
revoke a lease and force userspace to drop its page references.
I have also tagged these for -stable to purposely break cases that might
assume that longterm memory registrations for filesystem-dax mappings
were supported by the kernel. The behavior regression this policy
change implies is one of the reasons we maintain the "dax enabled.
Warning: EXPERIMENTAL, use at your own risk" notification when mounting
a filesystem in dax mode.
It is worth noting the device-dax interface does not suffer the same
constraints since it does not support file space management operations
like hole-punch.
This patch (of 4):
Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow long standing memory registrations against
filesytem-dax vmas. Device-dax vmas do not have this problem and are
explicitly allowed.
This is temporary until a "memory registration with layout-lease"
mechanism can be implemented for the affected sub-systems (RDMA and
V4L2).
[akpm(a)linux-foundation.org: use kcalloc()]
Link: http://lkml.kernel.org/r/151068939435.7446.13560129395419350737.stgit@dwill…
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Suggested-by: Christoph Hellwig <hch(a)lst.de>
Cc: Doug Ledford <dledford(a)redhat.com>
Cc: Hal Rosenstock <hal.rosenstock(a)gmail.com>
Cc: Inki Dae <inki.dae(a)samsung.com>
Cc: Jan Kara <jack(a)suse.cz>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Jeff Moyer <jmoyer(a)redhat.com>
Cc: Joonyoung Shim <jy0922.shim(a)samsung.com>
Cc: Kyungmin Park <kyungmin.park(a)samsung.com>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Cc: Sean Hefty <sean.hefty(a)intel.com>
Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
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>
---
include/linux/dax.h | 5 ----
include/linux/fs.h | 20 ++++++++++++++++
include/linux/mm.h | 13 ++++++++++
mm/gup.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 97 insertions(+), 5 deletions(-)
diff --git a/include/linux/dax.h b/include/linux/dax.h
index add6c4bc568f..ed9cf2f5cd06 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -61,11 +61,6 @@ static inline int dax_pmd_fault(struct vm_area_struct *vma, unsigned long addr,
int dax_pfn_mkwrite(struct vm_area_struct *, struct vm_fault *);
#define dax_mkwrite(vma, vmf, gb) dax_fault(vma, vmf, gb)
-static inline bool vma_is_dax(struct vm_area_struct *vma)
-{
- return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
-}
-
static inline bool dax_mapping(struct address_space *mapping)
{
return mapping->host && IS_DAX(mapping->host);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index d705ae084edd..745ea1b2e02c 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -18,6 +18,7 @@
#include <linux/bug.h>
#include <linux/mutex.h>
#include <linux/rwsem.h>
+#include <linux/mm_types.h>
#include <linux/capability.h>
#include <linux/semaphore.h>
#include <linux/fiemap.h>
@@ -3033,6 +3034,25 @@ static inline bool io_is_direct(struct file *filp)
return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);
}
+static inline bool vma_is_dax(struct vm_area_struct *vma)
+{
+ return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
+}
+
+static inline bool vma_is_fsdax(struct vm_area_struct *vma)
+{
+ struct inode *inode;
+
+ if (!vma->vm_file)
+ return false;
+ if (!vma_is_dax(vma))
+ return false;
+ inode = file_inode(vma->vm_file);
+ if (inode->i_mode == S_IFCHR)
+ return false; /* device-dax */
+ return true;
+}
+
static inline int iocb_flags(struct file *file)
{
int res = 0;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2217e2f18247..8e506783631b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1288,6 +1288,19 @@ long __get_user_pages_unlocked(struct task_struct *tsk, struct mm_struct *mm,
struct page **pages, unsigned int gup_flags);
long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
struct page **pages, unsigned int gup_flags);
+#ifdef CONFIG_FS_DAX
+long get_user_pages_longterm(unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas);
+#else
+static inline long get_user_pages_longterm(unsigned long start,
+ unsigned long nr_pages, unsigned int gup_flags,
+ struct page **pages, struct vm_area_struct **vmas)
+{
+ return get_user_pages(start, nr_pages, gup_flags, pages, vmas);
+}
+#endif /* CONFIG_FS_DAX */
+
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
diff --git a/mm/gup.c b/mm/gup.c
index c63a0341ae38..6c3b4e822946 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -982,6 +982,70 @@ long get_user_pages(unsigned long start, unsigned long nr_pages,
}
EXPORT_SYMBOL(get_user_pages);
+#ifdef CONFIG_FS_DAX
+/*
+ * This is the same as get_user_pages() in that it assumes we are
+ * operating on the current task's mm, but it goes further to validate
+ * that the vmas associated with the address range are suitable for
+ * longterm elevated page reference counts. For example, filesystem-dax
+ * mappings are subject to the lifetime enforced by the filesystem and
+ * we need guarantees that longterm users like RDMA and V4L2 only
+ * establish mappings that have a kernel enforced revocation mechanism.
+ *
+ * "longterm" == userspace controlled elevated page count lifetime.
+ * Contrast this to iov_iter_get_pages() usages which are transient.
+ */
+long get_user_pages_longterm(unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas_arg)
+{
+ struct vm_area_struct **vmas = vmas_arg;
+ struct vm_area_struct *vma_prev = NULL;
+ long rc, i;
+
+ if (!pages)
+ return -EINVAL;
+
+ if (!vmas) {
+ vmas = kcalloc(nr_pages, sizeof(struct vm_area_struct *),
+ GFP_KERNEL);
+ if (!vmas)
+ return -ENOMEM;
+ }
+
+ rc = get_user_pages(start, nr_pages, gup_flags, pages, vmas);
+
+ for (i = 0; i < rc; i++) {
+ struct vm_area_struct *vma = vmas[i];
+
+ if (vma == vma_prev)
+ continue;
+
+ vma_prev = vma;
+
+ if (vma_is_fsdax(vma))
+ break;
+ }
+
+ /*
+ * Either get_user_pages() failed, or the vma validation
+ * succeeded, in either case we don't need to put_page() before
+ * returning.
+ */
+ if (i >= rc)
+ goto out;
+
+ for (i = 0; i < rc; i++)
+ put_page(pages[i]);
+ rc = -EOPNOTSUPP;
+out:
+ if (vmas != vmas_arg)
+ kfree(vmas);
+ return rc;
+}
+EXPORT_SYMBOL(get_user_pages_longterm);
+#endif /* CONFIG_FS_DAX */
+
/**
* populate_vma_page_range() - populate a range of pages in the vma.
* @vma: target vma
This is a note to let you know that I've just added the patch titled
mm: Fix devm_memremap_pages() collision 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:
mm-fix-devm_memremap_pages-collision-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 foo@baz Mon Feb 26 20:55:53 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Fri, 23 Feb 2018 14:06:10 -0800
Subject: mm: Fix devm_memremap_pages() collision handling
To: gregkh(a)linuxfoundation.org
Cc:
Message-ID: <151942357089.21775.3486425046348885247.stgit(a)dwillia2-desk3.amr.corp.intel.com>
From: Jan H. Schönherr <jschoenh(a)amazon.de>
commit 77dd66a3c67c93ab401ccc15efff25578be281fd upstream.
If devm_memremap_pages() detects a collision while adding entries
to the radix-tree, we call pgmap_radix_release(). Unfortunately,
the function removes *all* entries for the range -- including the
entries that caused the collision in the first place.
Modify pgmap_radix_release() to take an additional argument to
indicate where to stop, so that only newly added entries are removed
from the tree.
Cc: <stable(a)vger.kernel.org>
Fixes: 9476df7d80df ("mm: introduce find_dev_pagemap()")
Signed-off-by: Jan H. Schönherr <jschoenh(a)amazon.de>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/memremap.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -194,7 +194,7 @@ void put_zone_device_page(struct page *p
}
EXPORT_SYMBOL(put_zone_device_page);
-static void pgmap_radix_release(struct resource *res)
+static void pgmap_radix_release(struct resource *res, resource_size_t end_key)
{
resource_size_t key, align_start, align_size, align_end;
@@ -203,8 +203,11 @@ static void pgmap_radix_release(struct r
align_end = align_start + align_size - 1;
mutex_lock(&pgmap_lock);
- for (key = res->start; key <= res->end; key += SECTION_SIZE)
+ for (key = res->start; key <= res->end; key += SECTION_SIZE) {
+ if (key >= end_key)
+ break;
radix_tree_delete(&pgmap_radix, key >> PA_SECTION_SHIFT);
+ }
mutex_unlock(&pgmap_lock);
}
@@ -255,7 +258,7 @@ static void devm_memremap_pages_release(
unlock_device_hotplug();
untrack_pfn(NULL, PHYS_PFN(align_start), align_size);
- pgmap_radix_release(res);
+ pgmap_radix_release(res, -1);
dev_WARN_ONCE(dev, pgmap->altmap && pgmap->altmap->alloc,
"%s: failed to free all reserved pages\n", __func__);
}
@@ -289,7 +292,7 @@ struct dev_pagemap *find_dev_pagemap(res
void *devm_memremap_pages(struct device *dev, struct resource *res,
struct percpu_ref *ref, struct vmem_altmap *altmap)
{
- resource_size_t key, align_start, align_size, align_end;
+ resource_size_t key = 0, align_start, align_size, align_end;
pgprot_t pgprot = PAGE_KERNEL;
struct dev_pagemap *pgmap;
struct page_map *page_map;
@@ -392,7 +395,7 @@ void *devm_memremap_pages(struct device
untrack_pfn(NULL, PHYS_PFN(align_start), align_size);
err_pfn_remap:
err_radix:
- pgmap_radix_release(res);
+ pgmap_radix_release(res, key);
devres_free(page_map);
return ERR_PTR(error);
}
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/mm-fix-devm_memremap_pages-collision-handling.patch
queue-4.9/ib-core-disable-memory-registration-of-filesystem-dax-vmas.patch
queue-4.9/mm-avoid-spurious-bad-pmd-warning-messages.patch
queue-4.9/mm-introduce-get_user_pages_longterm.patch
queue-4.9/mm-fail-get_vaddr_frames-for-filesystem-dax-mappings.patch
queue-4.9/fs-dax.c-fix-inefficiency-in-dax_writeback_mapping_range.patch
queue-4.9/device-dax-implement-split-to-catch-invalid-munmap-attempts.patch
queue-4.9/v4l2-disable-filesystem-dax-mapping-support.patch
queue-4.9/libnvdimm-dax-fix-1gb-aligned-namespaces-vs-physical-misalignment.patch
queue-4.9/x86-entry-64-clear-extra-registers-beyond-syscall-arguments-to-reduce-speculation-attack-surface.patch
queue-4.9/libnvdimm-fix-integer-overflow-static-analysis-warning.patch
commit b7f0554a56f21fb3e636a627450a9add030889be upstream.
Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow V4L2, Exynos, and other frame vector users to create
long standing / irrevocable memory registrations against filesytem-dax
vmas.
[dan.j.williams(a)intel.com: add comment for vma_is_fsdax() check in get_vaddr_frames(), per Jan]
Link: http://lkml.kernel.org/r/151197874035.26211.4061781453123083667.stgit@dwill…
Link: http://lkml.kernel.org/r/151068939985.7446.15684639617389154187.stgit@dwill…
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Cc: Inki Dae <inki.dae(a)samsung.com>
Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com>
Cc: Joonyoung Shim <jy0922.shim(a)samsung.com>
Cc: Kyungmin Park <kyungmin.park(a)samsung.com>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Mel Gorman <mgorman(a)suse.de>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Doug Ledford <dledford(a)redhat.com>
Cc: Hal Rosenstock <hal.rosenstock(a)gmail.com>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Jeff Moyer <jmoyer(a)redhat.com>
Cc: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Cc: Sean Hefty <sean.hefty(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
---
mm/frame_vector.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/mm/frame_vector.c b/mm/frame_vector.c
index db77dcb38afd..375a103d7a56 100644
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -52,6 +52,18 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
ret = -EFAULT;
goto out;
}
+
+ /*
+ * While get_vaddr_frames() could be used for transient (kernel
+ * controlled lifetime) pinning of memory pages all current
+ * users establish long term (userspace controlled lifetime)
+ * page pinning. Treat get_vaddr_frames() like
+ * get_user_pages_longterm() and disallow it for filesystem-dax
+ * mappings.
+ */
+ if (vma_is_fsdax(vma))
+ return -EOPNOTSUPP;
+
if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
vec->got_ref = true;
vec->is_pfns = false;
From: Ross Zwisler <ross.zwisler(a)linux.intel.com>
commit d0f0931de936a0a468d7e59284d39581c16d3a73 upstream.
When the pmd_devmap() checks were added by 5c7fb56e5e3f ("mm, dax:
dax-pmd vs thp-pmd vs hugetlbfs-pmd") to add better support for DAX huge
pages, they were all added to the end of if() statements after existing
pmd_trans_huge() checks. So, things like:
- if (pmd_trans_huge(*pmd))
+ if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
When further checks were added after pmd_trans_unstable() checks by
commit 7267ec008b5c ("mm: postpone page table allocation until we have
page to map") they were also added at the end of the conditional:
+ if (pmd_trans_unstable(fe->pmd) || pmd_devmap(*fe->pmd))
This ordering is fine for pmd_trans_huge(), but doesn't work for
pmd_trans_unstable(). This is because DAX huge pages trip the bad_pmd()
check inside of pmd_none_or_trans_huge_or_clear_bad() (called by
pmd_trans_unstable()), which prints out a warning and returns 1. So, we
do end up doing the right thing, but only after spamming dmesg with
suspicious looking messages:
mm/pgtable-generic.c:39: bad pmd ffff8808daa49b88(84000001006000a5)
Reorder these checks in a helper so that pmd_devmap() is checked first,
avoiding the error messages, and add a comment explaining why the
ordering is important.
Fixes: commit 7267ec008b5c ("mm: postpone page table allocation until we have page to map")
Link: http://lkml.kernel.org/r/20170522215749.23516-1-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Cc: Pawel Lebioda <pawel.lebioda(a)intel.com>
Cc: "Darrick J. Wong" <darrick.wong(a)oracle.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Matthew Wilcox <mawilcox(a)microsoft.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Dave Jiang <dave.jiang(a)intel.com>
Cc: Xiong Zhou <xzhou(a)redhat.com>
Cc: Eryu Guan <eguan(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>
---
mm/memory.c | 40 ++++++++++++++++++++++++++++++----------
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e2e68767a373..d2db2c4eb0a4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2848,6 +2848,17 @@ static int __do_fault(struct fault_env *fe, pgoff_t pgoff,
return ret;
}
+/*
+ * The ordering of these checks is important for pmds with _PAGE_DEVMAP set.
+ * If we check pmd_trans_unstable() first we will trip the bad_pmd() check
+ * inside of pmd_none_or_trans_huge_or_clear_bad(). This will end up correctly
+ * returning 1 but not before it spams dmesg with the pmd_clear_bad() output.
+ */
+static int pmd_devmap_trans_unstable(pmd_t *pmd)
+{
+ return pmd_devmap(*pmd) || pmd_trans_unstable(pmd);
+}
+
static int pte_alloc_one_map(struct fault_env *fe)
{
struct vm_area_struct *vma = fe->vma;
@@ -2871,18 +2882,27 @@ static int pte_alloc_one_map(struct fault_env *fe)
map_pte:
/*
* If a huge pmd materialized under us just retry later. Use
- * pmd_trans_unstable() instead of pmd_trans_huge() to ensure the pmd
- * didn't become pmd_trans_huge under us and then back to pmd_none, as
- * a result of MADV_DONTNEED running immediately after a huge pmd fault
- * in a different thread of this mm, in turn leading to a misleading
- * pmd_trans_huge() retval. All we have to ensure is that it is a
- * regular pmd that we can walk with pte_offset_map() and we can do that
- * through an atomic read in C, which is what pmd_trans_unstable()
- * provides.
+ * pmd_trans_unstable() via pmd_devmap_trans_unstable() instead of
+ * pmd_trans_huge() to ensure the pmd didn't become pmd_trans_huge
+ * under us and then back to pmd_none, as a result of MADV_DONTNEED
+ * running immediately after a huge pmd fault in a different thread of
+ * this mm, in turn leading to a misleading pmd_trans_huge() retval.
+ * All we have to ensure is that it is a regular pmd that we can walk
+ * with pte_offset_map() and we can do that through an atomic read in
+ * C, which is what pmd_trans_unstable() provides.
*/
- if (pmd_trans_unstable(fe->pmd) || pmd_devmap(*fe->pmd))
+ if (pmd_devmap_trans_unstable(fe->pmd))
return VM_FAULT_NOPAGE;
+ /*
+ * At this point we know that our vmf->pmd points to a page of ptes
+ * and it cannot become pmd_none(), pmd_devmap() or pmd_trans_huge()
+ * for the duration of the fault. If a racing MADV_DONTNEED runs and
+ * we zap the ptes pointed to by our vmf->pmd, the vmf->ptl will still
+ * be valid and we will re-check to make sure the vmf->pte isn't
+ * pte_none() under vmf->ptl protection when we return to
+ * alloc_set_pte().
+ */
fe->pte = pte_offset_map_lock(vma->vm_mm, fe->pmd, fe->address,
&fe->ptl);
return 0;
@@ -3456,7 +3476,7 @@ static int handle_pte_fault(struct fault_env *fe)
fe->pte = NULL;
} else {
/* See comment in pte_alloc_one_map() */
- if (pmd_trans_unstable(fe->pmd) || pmd_devmap(*fe->pmd))
+ if (pmd_devmap_trans_unstable(fe->pmd))
return 0;
/*
* A regular pmd is established and it can't morph into a huge
commit 58738c495e15badd2015e19ff41f1f1ed55200bc upstream.
Dan reports:
The patch 62232e45f4a2: "libnvdimm: control (ioctl) messages for
nvdimm_bus and nvdimm devices" from Jun 8, 2015, leads to the
following static checker warning:
drivers/nvdimm/bus.c:1018 __nd_ioctl()
warn: integer overflows 'buf_len'
From a casual review, this seems like it might be a real bug. On
the first iteration we load some data into in_env[]. On the second
iteration we read a use controlled "in_size" from nd_cmd_in_size().
It can go up to UINT_MAX - 1. A high number means we will fill the
whole in_env[] buffer. But we potentially keep looping and adding
more to in_len so now it can be any value.
It simple enough to change, but it feels weird that we keep looping
even though in_env is totally full. Shouldn't we just return an
error if we don't have space for desc->in_num.
We keep looping because the size of the total input is allowed to be
bigger than the 'envelope' which is a subset of the payload that tells
us how much data to expect. For safety explicitly check that buf_len
does not overflow which is what the checker flagged.
Cc: <stable(a)vger.kernel.org>
Fixes: 62232e45f4a2: "libnvdimm: control (ioctl) messages for nvdimm_bus..."
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
---
drivers/nvdimm/bus.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index 0392eb8a0dea..8311a93cabd8 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -812,16 +812,17 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, struct nvdimm *nvdimm,
int read_only, unsigned int ioctl_cmd, unsigned long arg)
{
struct nvdimm_bus_descriptor *nd_desc = nvdimm_bus->nd_desc;
- size_t buf_len = 0, in_len = 0, out_len = 0;
static char out_env[ND_CMD_MAX_ENVELOPE];
static char in_env[ND_CMD_MAX_ENVELOPE];
const struct nd_cmd_desc *desc = NULL;
unsigned int cmd = _IOC_NR(ioctl_cmd);
void __user *p = (void __user *) arg;
struct device *dev = &nvdimm_bus->dev;
- struct nd_cmd_pkg pkg;
const char *cmd_name, *dimm_name;
+ u32 in_len = 0, out_len = 0;
unsigned long cmd_mask;
+ struct nd_cmd_pkg pkg;
+ u64 buf_len = 0;
void *buf;
int rc, i;
@@ -882,7 +883,7 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, struct nvdimm *nvdimm,
}
if (cmd == ND_CMD_CALL) {
- dev_dbg(dev, "%s:%s, idx: %llu, in: %zu, out: %zu, len %zu\n",
+ dev_dbg(dev, "%s:%s, idx: %llu, in: %u, out: %u, len %llu\n",
__func__, dimm_name, pkg.nd_command,
in_len, out_len, buf_len);
@@ -912,9 +913,9 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, struct nvdimm *nvdimm,
out_len += out_size;
}
- buf_len = out_len + in_len;
+ buf_len = (u64) out_len + (u64) in_len;
if (buf_len > ND_IOCTL_MAX_BUFLEN) {
- dev_dbg(dev, "%s:%s cmd: %s buf_len: %zu > %d\n", __func__,
+ dev_dbg(dev, "%s:%s cmd: %s buf_len: %llu > %d\n", __func__,
dimm_name, cmd_name, buf_len,
ND_IOCTL_MAX_BUFLEN);
return -EINVAL;
From: Jan Kara <jack(a)suse.cz>
commit 1eb643d02b21412e603b42cdd96010a2ac31c05f upstream.
dax_writeback_mapping_range() fails to update iteration index when
searching radix tree for entries needing cache flushing. Thus each
pagevec worth of entries is searched starting from the start which is
inefficient and prone to livelocks. Update index properly.
Link: http://lkml.kernel.org/r/20170619124531.21491-1-jack@suse.cz
Fixes: 9973c98ecfda3 ("dax: add support for fsync/sync")
Signed-off-by: Jan Kara <jack(a)suse.cz>
Reviewed-by: Ross Zwisler <ross.zwisler(a)linux.intel.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>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
---
fs/dax.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/dax.c b/fs/dax.c
index 800748f10b3d..71f87d74afe1 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -785,6 +785,7 @@ int dax_writeback_mapping_range(struct address_space *mapping,
if (ret < 0)
return ret;
}
+ start_index = indices[pvec.nr - 1] + 1;
}
return 0;
}
This is a note to let you know that I've just added the patch titled
drm/i915/breadcrumbs: Ignore unsubmitted signalers
to the 4.15-stable tree which can 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-i915-breadcrumbs-ignore-unsubmitted-signalers.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 117172c8f9d40ba1de8cb35c6e614422faa03330 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Tue, 13 Feb 2018 09:01:54 +0000
Subject: drm/i915/breadcrumbs: Ignore unsubmitted signalers
From: Chris Wilson <chris(a)chris-wilson.co.uk>
commit 117172c8f9d40ba1de8cb35c6e614422faa03330 upstream.
When a request is preempted, it is unsubmitted from the HW queue and
removed from the active list of breadcrumbs. In the process, this
however triggers the signaler and it may see the clear rbtree with the
old, and still valid, seqno, or it may match the cleared seqno with the
now zero rq->global_seqno. This confuses the signaler into action and
signaling the fence.
Fixes: d6a2289d9d6b ("drm/i915: Remove the preempted request from the execution queue")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # v4.12+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206094633.30181-1-chris@…
(cherry picked from commit fd10e2ce9905030d922e179a8047a4d50daffd8e)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180213090154.17373-1-chris@…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 29 ++++++++++-------------------
1 file changed, 10 insertions(+), 19 deletions(-)
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -552,29 +552,16 @@ void intel_engine_remove_wait(struct int
spin_unlock_irq(&b->rb_lock);
}
-static bool signal_valid(const struct drm_i915_gem_request *request)
-{
- return intel_wait_check_request(&request->signaling.wait, request);
-}
-
static bool signal_complete(const struct drm_i915_gem_request *request)
{
if (!request)
return false;
- /* If another process served as the bottom-half it may have already
- * signalled that this wait is already completed.
- */
- if (intel_wait_complete(&request->signaling.wait))
- return signal_valid(request);
-
- /* Carefully check if the request is complete, giving time for the
+ /*
+ * Carefully check if the request is complete, giving time for the
* seqno to be visible or if the GPU hung.
*/
- if (__i915_request_irq_complete(request))
- return true;
-
- return false;
+ return __i915_request_irq_complete(request);
}
static struct drm_i915_gem_request *to_signaler(struct rb_node *rb)
@@ -617,9 +604,13 @@ static int intel_breadcrumbs_signaler(vo
request = i915_gem_request_get_rcu(request);
rcu_read_unlock();
if (signal_complete(request)) {
- local_bh_disable();
- dma_fence_signal(&request->fence);
- local_bh_enable(); /* kick start the tasklets */
+ if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+ &request->fence.flags)) {
+ local_bh_disable();
+ dma_fence_signal(&request->fence);
+ GEM_BUG_ON(!i915_gem_request_completed(request));
+ local_bh_enable(); /* kick start the tasklets */
+ }
spin_lock_irq(&b->rb_lock);
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.15/drm-handle-unexpected-holes-in-color-eviction.patch
queue-4.15/drm-i915-breadcrumbs-ignore-unsubmitted-signalers.patch
This is a note to let you know that I've just added the patch titled
drm/i915/breadcrumbs: Ignore unsubmitted signalers
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-i915-breadcrumbs-ignore-unsubmitted-signalers.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 117172c8f9d40ba1de8cb35c6e614422faa03330 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Tue, 13 Feb 2018 09:01:54 +0000
Subject: drm/i915/breadcrumbs: Ignore unsubmitted signalers
From: Chris Wilson <chris(a)chris-wilson.co.uk>
commit 117172c8f9d40ba1de8cb35c6e614422faa03330 upstream.
When a request is preempted, it is unsubmitted from the HW queue and
removed from the active list of breadcrumbs. In the process, this
however triggers the signaler and it may see the clear rbtree with the
old, and still valid, seqno, or it may match the cleared seqno with the
now zero rq->global_seqno. This confuses the signaler into action and
signaling the fence.
Fixes: d6a2289d9d6b ("drm/i915: Remove the preempted request from the execution queue")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # v4.12+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206094633.30181-1-chris@…
(cherry picked from commit fd10e2ce9905030d922e179a8047a4d50daffd8e)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180213090154.17373-1-chris@…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 29 ++++++++++-------------------
1 file changed, 10 insertions(+), 19 deletions(-)
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -541,29 +541,16 @@ void intel_engine_remove_wait(struct int
spin_unlock_irq(&b->rb_lock);
}
-static bool signal_valid(const struct drm_i915_gem_request *request)
-{
- return intel_wait_check_request(&request->signaling.wait, request);
-}
-
static bool signal_complete(const struct drm_i915_gem_request *request)
{
if (!request)
return false;
- /* If another process served as the bottom-half it may have already
- * signalled that this wait is already completed.
- */
- if (intel_wait_complete(&request->signaling.wait))
- return signal_valid(request);
-
- /* Carefully check if the request is complete, giving time for the
+ /*
+ * Carefully check if the request is complete, giving time for the
* seqno to be visible or if the GPU hung.
*/
- if (__i915_request_irq_complete(request))
- return true;
-
- return false;
+ return __i915_request_irq_complete(request);
}
static struct drm_i915_gem_request *to_signaler(struct rb_node *rb)
@@ -606,9 +593,13 @@ static int intel_breadcrumbs_signaler(vo
request = i915_gem_request_get_rcu(request);
rcu_read_unlock();
if (signal_complete(request)) {
- local_bh_disable();
- dma_fence_signal(&request->fence);
- local_bh_enable(); /* kick start the tasklets */
+ if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+ &request->fence.flags)) {
+ local_bh_disable();
+ dma_fence_signal(&request->fence);
+ GEM_BUG_ON(!i915_gem_request_completed(request));
+ local_bh_enable(); /* kick start the tasklets */
+ }
spin_lock_irq(&b->rb_lock);
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.14/drm-handle-unexpected-holes-in-color-eviction.patch
queue-4.14/drm-i915-breadcrumbs-ignore-unsubmitted-signalers.patch
From: Eric Biggers <ebiggers(a)google.com>
commit 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 upstream.
[Please apply to 4.9-stable. I dropped the portion of the patch
pertaining to KEYCTL_RESTRICT_KEYRING which was added in v4.12.]
The asymmetric key type allows an X.509 certificate to be added even if
its signature's hash algorithm is not available in the crypto API. In
that case 'payload.data[asym_auth]' will be NULL. But the key
restriction code failed to check for this case before trying to use the
signature, resulting in a NULL pointer dereference in
key_or_keyring_common() or in restrict_link_by_signature().
Fix this by returning -ENOPKG when the signature is unsupported.
Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled and
keyctl has support for the 'restrict_keyring' command:
keyctl new_session
keyctl restrict_keyring @s asymmetric builtin_trusted
openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @s
Fixes: a511e1af8b12 ("KEYS: Move the point of trust determination to __key_link()")
Cc: <stable(a)vger.kernel.org> # v4.7+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
---
crypto/asymmetric_keys/restrict.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/crypto/asymmetric_keys/restrict.c b/crypto/asymmetric_keys/restrict.c
index 19d1afb9890f..09b1374dc619 100644
--- a/crypto/asymmetric_keys/restrict.c
+++ b/crypto/asymmetric_keys/restrict.c
@@ -66,8 +66,9 @@ __setup("ca_keys=", ca_keys_setup);
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we couldn't find a
* matching parent certificate in the trusted list, -EKEYREJECTED if the
- * signature check fails or the key is blacklisted and some other error if
- * there is a matching certificate but the signature check cannot be performed.
+ * signature check fails or the key is blacklisted, -ENOPKG if the signature
+ * uses unsupported crypto, or some other error if there is a matching
+ * certificate but the signature check cannot be performed.
*/
int restrict_link_by_signature(struct key *trust_keyring,
const struct key_type *type,
@@ -86,6 +87,8 @@ int restrict_link_by_signature(struct key *trust_keyring,
return -EOPNOTSUPP;
sig = payload->data[asym_auth];
+ if (!sig)
+ return -ENOPKG;
if (!sig->auth_ids[0] && !sig->auth_ids[1])
return -ENOKEY;
--
2.16.1.291.g4437f3f132-goog
From: Eric Biggers <ebiggers(a)google.com>
commit e0058f3a874ebb48b25be7ff79bc3b4e59929f90 upstream.
[Please apply to 3.18-stable. Patch was fixed up to drop usage of
ASN.1 state machine opcodes which were added in 4.3.]
In asn1_ber_decoder(), indefinitely-sized ASN.1 items were being passed
to the action functions before their lengths had been computed, using
the bogus length of 0x80 (ASN1_INDEFINITE_LENGTH). This resulted in
reading data past the end of the input buffer, when given a specially
crafted message.
Fix it by rearranging the code so that the indefinite length is resolved
before the action is called.
This bug was originally found by fuzzing the X.509 parser in userspace
using libFuzzer from the LLVM project.
KASAN report (cleaned up slightly):
BUG: KASAN: slab-out-of-bounds in memcpy ./include/linux/string.h:341 [inline]
BUG: KASAN: slab-out-of-bounds in x509_fabricate_name.constprop.1+0x1a4/0x940 crypto/asymmetric_keys/x509_cert_parser.c:366
Read of size 128 at addr ffff880035dd9eaf by task keyctl/195
CPU: 1 PID: 195 Comm: keyctl Not tainted 4.14.0-09238-g1d3b78bbc6e9 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0xd1/0x175 lib/dump_stack.c:53
print_address_description+0x78/0x260 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x23f/0x350 mm/kasan/report.c:409
memcpy+0x1f/0x50 mm/kasan/kasan.c:302
memcpy ./include/linux/string.h:341 [inline]
x509_fabricate_name.constprop.1+0x1a4/0x940 crypto/asymmetric_keys/x509_cert_parser.c:366
asn1_ber_decoder+0xb4a/0x1fd0 lib/asn1_decoder.c:447
x509_cert_parse+0x1c7/0x620 crypto/asymmetric_keys/x509_cert_parser.c:89
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Allocated by task 195:
__do_kmalloc_node mm/slab.c:3675 [inline]
__kmalloc_node+0x47/0x60 mm/slab.c:3682
kvmalloc ./include/linux/mm.h:540 [inline]
SYSC_add_key security/keys/keyctl.c:104 [inline]
SyS_add_key+0x19e/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Reported-by: Alexander Potapenko <glider(a)google.com>
Cc: <stable(a)vger.kernel.org> # v3.7+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
---
lib/asn1_decoder.c | 43 ++++++++++++++++++++++++-------------------
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/lib/asn1_decoder.c b/lib/asn1_decoder.c
index 7f453b6ff0d0..c3a768ae1a40 100644
--- a/lib/asn1_decoder.c
+++ b/lib/asn1_decoder.c
@@ -305,38 +305,43 @@ next_op:
/* Decide how to handle the operation */
switch (op) {
- case ASN1_OP_MATCH_ANY_ACT:
- case ASN1_OP_COND_MATCH_ANY_ACT:
- ret = actions[machine[pc + 1]](context, hdr, tag, data + dp, len);
- if (ret < 0)
- return ret;
- goto skip_data;
-
- case ASN1_OP_MATCH_ACT:
- case ASN1_OP_MATCH_ACT_OR_SKIP:
- case ASN1_OP_COND_MATCH_ACT_OR_SKIP:
- ret = actions[machine[pc + 2]](context, hdr, tag, data + dp, len);
- if (ret < 0)
- return ret;
- goto skip_data;
-
case ASN1_OP_MATCH:
case ASN1_OP_MATCH_OR_SKIP:
+ case ASN1_OP_MATCH_ACT:
+ case ASN1_OP_MATCH_ACT_OR_SKIP:
case ASN1_OP_MATCH_ANY:
+ case ASN1_OP_MATCH_ANY_ACT:
case ASN1_OP_COND_MATCH_OR_SKIP:
+ case ASN1_OP_COND_MATCH_ACT_OR_SKIP:
case ASN1_OP_COND_MATCH_ANY:
- skip_data:
+ case ASN1_OP_COND_MATCH_ANY_ACT:
+
if (!(flags & FLAG_CONS)) {
if (flags & FLAG_INDEFINITE_LENGTH) {
+ size_t tmp = dp;
+
ret = asn1_find_indefinite_length(
- data, datalen, &dp, &len, &errmsg);
+ data, datalen, &tmp, &len, &errmsg);
if (ret < 0)
goto error;
- } else {
- dp += len;
}
pr_debug("- LEAF: %zu\n", len);
}
+
+ if (op & ASN1_OP_MATCH__ACT) {
+ unsigned char act;
+
+ if (op & ASN1_OP_MATCH__ANY)
+ act = machine[pc + 1];
+ else
+ act = machine[pc + 2];
+ ret = actions[act](context, hdr, tag, data + dp, len);
+ if (ret < 0)
+ return ret;
+ }
+
+ if (!(flags & FLAG_CONS))
+ dp += len;
pc += asn1_op_lengths[op];
goto next_op;
--
2.16.1.291.g4437f3f132-goog
From: Eric Biggers <ebiggers(a)google.com>
[Please apply to 4.4-stable and 4.9-stable.]
When commit 4be5a2810489 ("binder: check for binder_thread allocation
failure in binder_poll()") was applied to 4.4-stable and 4.9-stable it
was forgotten to release the global binder lock in the new error path.
The global binder lock wasn't removed until v4.14, by commit
a60b890f607d ("binder: remove global binder lock").
Fix the new error path to release the lock.
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
drivers/android/binder.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 3b6ac80b2127..49199bd2ab93 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2628,8 +2628,10 @@ static unsigned int binder_poll(struct file *filp,
binder_lock(__func__);
thread = binder_get_thread(proc);
- if (!thread)
+ if (!thread) {
+ binder_unlock(__func__);
return POLLERR;
+ }
wait_for_proc_work = thread->transaction_stack == NULL &&
list_empty(&thread->todo) && thread->return_error == BR_OK;
--
2.16.1.291.g4437f3f132-goog
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
Add check for build_skb enabled ring in ixgbe_dma_sync_frag().
In that case &skb_shinfo(skb)->frags[0] may not always be set which
can lead to a crash. Instead we derive the page offset from skb->data.
Fixes: 42073d91a214
("ixgbe: Have the CPU take ownership of the buffers sooner")
CC: stable <stable(a)vger.kernel.org>
Reported-by: Ambarish Soman <asoman(a)redhat.com>
Suggested-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 0da5aa2c8aba..9fc063af233c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1888,6 +1888,14 @@ static void ixgbe_dma_sync_frag(struct ixgbe_ring *rx_ring,
ixgbe_rx_pg_size(rx_ring),
DMA_FROM_DEVICE,
IXGBE_RX_DMA_ATTR);
+ } else if (ring_uses_build_skb(rx_ring)) {
+ unsigned long offset = (unsigned long)(skb->data) & ~PAGE_MASK;
+
+ dma_sync_single_range_for_cpu(rx_ring->dev,
+ IXGBE_CB(skb)->dma,
+ offset,
+ skb_headlen(skb),
+ DMA_FROM_DEVICE);
} else {
struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[0];
--
2.14.3
Commit 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper") crashes my
QNAP TS-209 NAS early on boot.
The boot code for the TS-209 is looping through an ext2 filesystem on a
384kB mtd partition (factory configuration put there by QNAP). There it
looks on every 1kB boundary if there is a valid MAC address. The
filesystem has a 1kB block size, so this seems to work.
On my device the MAC address is on the 37th 1kB block. But: On the 27th
block is a large file (1,5kB) without 0 bytes inside. The code in
qnap_tsx09_find_mac_addr() maps 1kB into memory (not a whole file or the
whole 384kB) and then calls qnap_tsx09_check_mac_addr() -> mac_pton() ->
strlen() on this memory block. as there is no 0 byte in the file on the
27th block, strlen() runs into bad memory and the machine panics. The old
code had no strlen().
Actually mac_pton() doesn't need to call strlen(), the following loop
catches short strings quite nicely. The strlen() seems to be an
optimization for calls to mac_pton with empty string. But this is rarely
the case and this is not a hot path. Remove it to reduce code size and
speed up calls with an not empty string.
Besides fixing the crash there is are other users interested in
this change, see https://patchwork.ozlabs.org/patch/851008/
Fixes: 4904dbda41c8 ("ARM: orion5x: use mac_pton() helper")
Signed-off-by: Stefan Hellermann <stefan(a)the2masters.de>
Cc: <stable(a)vger.kernel.org> [4.4+]
---
lib/net_utils.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/lib/net_utils.c b/lib/net_utils.c
index af525353395d..9d38da67ee44 100644
--- a/lib/net_utils.c
+++ b/lib/net_utils.c
@@ -8,10 +8,6 @@ bool mac_pton(const char *s, u8 *mac)
{
int i;
- /* XX:XX:XX:XX:XX:XX */
- if (strlen(s) < 3 * ETH_ALEN - 1)
- return false;
-
/* Don't dirty result unless string is valid MAC. */
for (i = 0; i < ETH_ALEN; i++) {
if (!isxdigit(s[i * 3]) || !isxdigit(s[i * 3 + 1]))
--
2.11.0
This is a note to let you know that I've just added the patch titled
arm64: __show_regs: Only resolve kernel symbols when running at EL1
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-__show_regs-only-resolve-kernel-symbols-when-running-at-el1.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a06f818a70de21b4b3b4186816094208fc7accf9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 19 Feb 2018 16:46:57 +0000
Subject: arm64: __show_regs: Only resolve kernel symbols when running at EL1
From: Will Deacon <will.deacon(a)arm.com>
commit a06f818a70de21b4b3b4186816094208fc7accf9 upstream.
__show_regs pretty prints PC and LR by attempting to map them to kernel
function names to improve the utility of crash reports. Unfortunately,
this mapping is applied even when the pt_regs corresponds to user mode,
resulting in a KASLR oracle.
Avoid this issue by only looking up the function symbols when the register
state indicates that we're actually running at EL1.
Cc: <stable(a)vger.kernel.org>
Reported-by: NCSC Security <security(a)ncsc.gov.uk>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/process.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -221,8 +221,15 @@ void __show_regs(struct pt_regs *regs)
show_regs_print_info(KERN_DEFAULT);
print_pstate(regs);
- print_symbol("pc : %s\n", regs->pc);
- print_symbol("lr : %s\n", lr);
+
+ if (!user_mode(regs)) {
+ print_symbol("pc : %s\n", regs->pc);
+ print_symbol("lr : %s\n", lr);
+ } else {
+ printk("pc : %016llx\n", regs->pc);
+ printk("lr : %016llx\n", lr);
+ }
+
printk("sp : %016llx\n", sp);
i = top_reg;
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.15/arm64-remove-unimplemented-syscall-log-message.patch
queue-4.15/arm64-mm-don-t-write-garbage-into-ttbr1_el1-register.patch
queue-4.15/arm64-disable-unhandled-signal-log-messages-by-default.patch
queue-4.15/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
queue-4.15/arm64-__show_regs-only-resolve-kernel-symbols-when-running-at-el1.patch
queue-4.15/arm64-cpufeature-fix-ctr_el0-field-definitions.patch
queue-4.15/kbuild-always-define-endianess-in-kconfig.h.patch
The patch below does not apply to the 4.15-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 a06f818a70de21b4b3b4186816094208fc7accf9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 19 Feb 2018 16:46:57 +0000
Subject: [PATCH] arm64: __show_regs: Only resolve kernel symbols when running
at EL1
__show_regs pretty prints PC and LR by attempting to map them to kernel
function names to improve the utility of crash reports. Unfortunately,
this mapping is applied even when the pt_regs corresponds to user mode,
resulting in a KASLR oracle.
Avoid this issue by only looking up the function symbols when the register
state indicates that we're actually running at EL1.
Cc: <stable(a)vger.kernel.org>
Reported-by: NCSC Security <security(a)ncsc.gov.uk>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ad8aeb098b31..c0da6efe5465 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -220,8 +220,15 @@ void __show_regs(struct pt_regs *regs)
show_regs_print_info(KERN_DEFAULT);
print_pstate(regs);
- printk("pc : %pS\n", (void *)regs->pc);
- printk("lr : %pS\n", (void *)lr);
+
+ if (!user_mode(regs)) {
+ printk("pc : %pS\n", (void *)regs->pc);
+ printk("lr : %pS\n", (void *)lr);
+ } else {
+ printk("pc : %016llx\n", regs->pc);
+ printk("lr : %016llx\n", lr);
+ }
+
printk("sp : %016llx\n", sp);
i = top_reg;
This is a note to let you know that I've just added the patch titled
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
to the 4.15-stable tree which can 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-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 85c615eb52222bc5fab6c7190d146bc59fac289e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 20 Feb 2018 21:58:21 +0100
Subject: x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
From: Arnd Bergmann <arnd(a)arndb.de>
commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
data from CPU 0 to all other CPUs, which when building a non-SMP
kernel turns into a memcpy() with identical source and destination
pointers:
arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
memcpy(per_cpu(cpu_msrs, cpu).multiplex,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
per_cpu(cpu_msrs, 0).multiplex,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(struct op_msr) * model->num_virt_counters);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
I have analyzed a number of such warnings now: some are valid and the
GCC warning is welcome. Others turned out to be false-positives, and
GCC was changed to not warn about those any more. This is a corner case
that is a false-positive but the GCC developers feel it's better to keep
warning about it.
In this case, it seems best to work around it by telling GCC
a little more clearly that this code path is never hit with
an IS_ENABLED() configuration check.
Cc:stable as we also want old kernels to build cleanly with GCC-8.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Jessica Yu <jeyu(a)kernel.org>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Martin Sebor <msebor(a)gcc.gnu.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Robert Richter <rric(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: oprofile-list(a)lists.sf.net
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/nmi_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -460,7 +460,7 @@ static int nmi_setup(void)
goto fail;
for_each_possible_cpu(cpu) {
- if (!cpu)
+ if (!IS_ENABLED(CONFIG_SMP) || !cpu)
continue;
memcpy(per_cpu(cpu_msrs, cpu).counters,
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.15/cfg80211-fix-cfg80211_beacon_dup.patch
queue-4.15/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
x86/apic/vector: Handle vector release on CPU unplug correctly
to the 4.15-stable tree which can 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-apic-vector-handle-vector-release-on-cpu-unplug-correctly.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e84cf6aa501c58bf4bf451f1e425192ec090aed2 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx(a)linutronix.de>
Date: Thu, 22 Feb 2018 12:08:06 +0100
Subject: x86/apic/vector: Handle vector release on CPU unplug correctly
From: Thomas Gleixner <tglx(a)linutronix.de>
commit e84cf6aa501c58bf4bf451f1e425192ec090aed2 upstream.
When a irq vector is replaced, then the previous vector is normally
released when the first interrupt happens on the new vector. If the target
CPU of the previous vector is already offline when the new vector is
installed, then the previous vector is silently discarded, which leads to
accounting issues causing suspend failures and other problems.
Adjust the logic so that the previous vector is freed in the underlying
matrix allocator to ensure that the accounting stays correct.
Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment")
Reported-by: Yuriy Vostrikov <delamonpansie(a)gmail.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Tested-by: Yuriy Vostrikov <delamonpansie(a)gmail.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20180222112316.930791749@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/apic/vector.c | 25 ++++++++++++++++++++++---
1 file changed, 22 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -134,21 +134,40 @@ static void apic_update_vector(struct ir
{
struct apic_chip_data *apicd = apic_chip_data(irqd);
struct irq_desc *desc = irq_data_to_desc(irqd);
+ bool managed = irqd_affinity_is_managed(irqd);
lockdep_assert_held(&vector_lock);
trace_vector_update(irqd->irq, newvec, newcpu, apicd->vector,
apicd->cpu);
- /* Setup the vector move, if required */
- if (apicd->vector && cpu_online(apicd->cpu)) {
+ /*
+ * If there is no vector associated or if the associated vector is
+ * the shutdown vector, which is associated to make PCI/MSI
+ * shutdown mode work, then there is nothing to release. Clear out
+ * prev_vector for this and the offlined target case.
+ */
+ apicd->prev_vector = 0;
+ if (!apicd->vector || apicd->vector == MANAGED_IRQ_SHUTDOWN_VECTOR)
+ goto setnew;
+ /*
+ * If the target CPU of the previous vector is online, then mark
+ * the vector as move in progress and store it for cleanup when the
+ * first interrupt on the new vector arrives. If the target CPU is
+ * offline then the regular release mechanism via the cleanup
+ * vector is not possible and the vector can be immediately freed
+ * in the underlying matrix allocator.
+ */
+ if (cpu_online(apicd->cpu)) {
apicd->move_in_progress = true;
apicd->prev_vector = apicd->vector;
apicd->prev_cpu = apicd->cpu;
} else {
- apicd->prev_vector = 0;
+ irq_matrix_free(vector_matrix, apicd->cpu, apicd->vector,
+ managed);
}
+setnew:
apicd->vector = newvec;
apicd->cpu = newcpu;
BUG_ON(!IS_ERR_OR_NULL(per_cpu(vector_irq, newcpu)[newvec]));
Patches currently in stable-queue which might be from tglx(a)linutronix.de are
queue-4.15/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-4.15/x86-apic-vector-handle-vector-release-on-cpu-unplug-correctly.patch
queue-4.15/genirq-matrix-handle-cpu-offlining-proper.patch
queue-4.15/kbuild-always-define-endianess-in-kconfig.h.patch
This is a note to let you know that I've just added the patch titled
X.509: fix NULL dereference when restricting key with unsupported_sig
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 22 Feb 2018 14:38:34 +0000
Subject: X.509: fix NULL dereference when restricting key with unsupported_sig
From: Eric Biggers <ebiggers(a)google.com>
commit 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 upstream.
The asymmetric key type allows an X.509 certificate to be added even if
its signature's hash algorithm is not available in the crypto API. In
that case 'payload.data[asym_auth]' will be NULL. But the key
restriction code failed to check for this case before trying to use the
signature, resulting in a NULL pointer dereference in
key_or_keyring_common() or in restrict_link_by_signature().
Fix this by returning -ENOPKG when the signature is unsupported.
Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled and
keyctl has support for the 'restrict_keyring' command:
keyctl new_session
keyctl restrict_keyring @s asymmetric builtin_trusted
openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @s
Fixes: a511e1af8b12 ("KEYS: Move the point of trust determination to __key_link()")
Cc: <stable(a)vger.kernel.org> # v4.7+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/asymmetric_keys/restrict.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--- a/crypto/asymmetric_keys/restrict.c
+++ b/crypto/asymmetric_keys/restrict.c
@@ -67,8 +67,9 @@ __setup("ca_keys=", ca_keys_setup);
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we couldn't find a
* matching parent certificate in the trusted list, -EKEYREJECTED if the
- * signature check fails or the key is blacklisted and some other error if
- * there is a matching certificate but the signature check cannot be performed.
+ * signature check fails or the key is blacklisted, -ENOPKG if the signature
+ * uses unsupported crypto, or some other error if there is a matching
+ * certificate but the signature check cannot be performed.
*/
int restrict_link_by_signature(struct key *dest_keyring,
const struct key_type *type,
@@ -88,6 +89,8 @@ int restrict_link_by_signature(struct ke
return -EOPNOTSUPP;
sig = payload->data[asym_auth];
+ if (!sig)
+ return -ENOPKG;
if (!sig->auth_ids[0] && !sig->auth_ids[1])
return -ENOKEY;
@@ -139,6 +142,8 @@ static int key_or_keyring_common(struct
return -EOPNOTSUPP;
sig = payload->data[asym_auth];
+ if (!sig)
+ return -ENOPKG;
if (!sig->auth_ids[0] && !sig->auth_ids[1])
return -ENOKEY;
@@ -222,9 +227,9 @@ static int key_or_keyring_common(struct
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we
* couldn't find a matching parent certificate in the trusted list,
- * -EKEYREJECTED if the signature check fails, and some other error if
- * there is a matching certificate but the signature check cannot be
- * performed.
+ * -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses
+ * unsupported crypto, or some other error if there is a matching certificate
+ * but the signature check cannot be performed.
*/
int restrict_link_by_key_or_keyring(struct key *dest_keyring,
const struct key_type *type,
@@ -249,9 +254,9 @@ int restrict_link_by_key_or_keyring(stru
*
* Returns 0 if the new certificate was accepted, -ENOKEY if we
* couldn't find a matching parent certificate in the trusted list,
- * -EKEYREJECTED if the signature check fails, and some other error if
- * there is a matching certificate but the signature check cannot be
- * performed.
+ * -EKEYREJECTED if the signature check fails, -ENOPKG if the signature uses
+ * unsupported crypto, or some other error if there is a matching certificate
+ * but the signature check cannot be performed.
*/
int restrict_link_by_key_or_keyring_chain(struct key *dest_keyring,
const struct key_type *type,
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/pkcs-7-fix-certificate-blacklisting.patch
queue-4.15/x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch
queue-4.15/x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch
queue-4.15/pkcs-7-fix-certificate-chain-verification.patch
This is a note to let you know that I've just added the patch titled
X.509: fix BUG_ON() when hash algorithm is unsupported
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 437499eea4291ae9621e8763a41df027c110a1ef Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 22 Feb 2018 14:38:33 +0000
Subject: X.509: fix BUG_ON() when hash algorithm is unsupported
From: Eric Biggers <ebiggers(a)google.com>
commit 437499eea4291ae9621e8763a41df027c110a1ef upstream.
The X.509 parser mishandles the case where the certificate's signature's
hash algorithm is not available in the crypto API. In this case,
x509_get_sig_params() doesn't allocate the cert->sig->digest buffer;
this part seems to be intentional. However,
public_key_verify_signature() is still called via
x509_check_for_self_signed(), which triggers the 'BUG_ON(!sig->digest)'.
Fix this by making public_key_verify_signature() return -ENOPKG if the
hash buffer has not been allocated.
Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled:
openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @s
Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
Reported-by: Paolo Valente <paolo.valente(a)linaro.org>
Cc: Paolo Valente <paolo.valente(a)linaro.org>
Cc: <stable(a)vger.kernel.org> # v4.7+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/asymmetric_keys/public_key.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -79,9 +79,11 @@ int public_key_verify_signature(const st
BUG_ON(!pkey);
BUG_ON(!sig);
- BUG_ON(!sig->digest);
BUG_ON(!sig->s);
+ if (!sig->digest)
+ return -ENOPKG;
+
alg_name = sig->pkey_algo;
if (strcmp(sig->pkey_algo, "rsa") == 0) {
/* The data wangled by the RSA algorithm is typically padded
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/pkcs-7-fix-certificate-blacklisting.patch
queue-4.15/x.509-fix-null-dereference-when-restricting-key-with-unsupported_sig.patch
queue-4.15/x.509-fix-bug_on-when-hash-algorithm-is-unsupported.patch
queue-4.15/pkcs-7-fix-certificate-chain-verification.patch
This is a note to let you know that I've just added the patch titled
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
to the 4.15-stable tree which can 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-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 17aa31f13cad25daa19d3f923323f552e87bc874 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Mon, 5 Feb 2018 17:12:35 +0900
Subject: usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
commit 17aa31f13cad25daa19d3f923323f552e87bc874 upstream.
This fixes an issue that a gadget driver (usb_f_fs) is possible to
stop rx transactions after the usb-dmac is used because the following
functions missed to set/check the "running" flag.
- usbhsf_dma_prepare_pop_with_usb_dmac()
- usbhsf_dma_pop_done_with_usb_dmac()
So, if next transaction uses pio, the usbhsf_prepare_pop() can not
start the transaction because the "running" flag is 0.
Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
Cc: <stable(a)vger.kernel.org> # v3.19+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/renesas_usbhs/fifo.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -989,6 +989,10 @@ static int usbhsf_dma_prepare_pop_with_u
if ((uintptr_t)pkt->buf & (USBHS_USB_DMAC_XFER_SIZE - 1))
goto usbhsf_pio_prepare_pop;
+ /* return at this time if the pipe is running */
+ if (usbhs_pipe_is_running(pipe))
+ return 0;
+
usbhs_pipe_config_change_bfre(pipe, 1);
ret = usbhsf_fifo_select(pipe, fifo, 0);
@@ -1179,6 +1183,7 @@ static int usbhsf_dma_pop_done_with_usb_
usbhsf_fifo_clear(pipe, fifo);
pkt->actual = usbhs_dma_calc_received_size(pkt, chan, rcv_len);
+ usbhs_pipe_running(pipe, 0);
usbhsf_dma_stop(pipe, fifo);
usbhsf_dma_unmap(pkt);
usbhsf_fifo_unselect(pipe, pipe->fifo);
Patches currently in stable-queue which might be from yoshihiro.shimoda.uh(a)renesas.com are
queue-4.15/usb-renesas_usbhs-missed-the-running-flag-in-usb_dmac-with-rx-path.patch
This is a note to let you know that I've just added the patch titled
usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28
to the 4.15-stable tree which can 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-mxs-fix-null-pointer-dereference-on-i.mx23-28.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 499350865387f8b8c40a9e9453a9a7eb3cec5dc4 Mon Sep 17 00:00:00 2001
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Thu, 18 Jan 2018 00:22:45 -0200
Subject: usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28
From: Fabio Estevam <fabio.estevam(a)nxp.com>
commit 499350865387f8b8c40a9e9453a9a7eb3cec5dc4 upstream.
Commit e93650994a95 ("usb: phy: mxs: add usb charger type detection")
causes the following kernel hang on i.MX28:
[ 2.207973] usbcore: registered new interface driver usb-storage
[ 2.235659] Unable to handle kernel NULL pointer dereference at virtual address 00000188
[ 2.244195] pgd = (ptrval)
[ 2.246994] [00000188] *pgd=00000000
[ 2.250676] Internal error: Oops: 5 [#1] ARM
[ 2.254979] Modules linked in:
[ 2.258089] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc8-next-20180117-00002-g75d5f21 #7
[ 2.266724] Hardware name: Freescale MXS (Device Tree)
[ 2.271921] PC is at regmap_read+0x0/0x5c
[ 2.275977] LR is at mxs_phy_charger_detect+0x34/0x1dc
mxs_phy_charger_detect() makes accesses to the anatop registers via regmap,
however i.MX23/28 do not have such registers, which causes a NULL pointer
dereference.
Fix the issue by doing a NULL check on the 'regmap' pointer.
Fixes: e93650994a95 ("usb: phy: mxs: add usb charger type detection")
Cc: <stable(a)vger.kernel.org> # v4.15
Reviewed-by: Li Jun <jun.li(a)nxp.com>
Acked-by: Peter Chen <peter.chen(a)nxp.com>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/phy/phy-mxs-usb.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -602,6 +602,9 @@ static enum usb_charger_type mxs_phy_cha
void __iomem *base = phy->io_priv;
enum usb_charger_type chgr_type = UNKNOWN_TYPE;
+ if (!regmap)
+ return UNKNOWN_TYPE;
+
if (mxs_charger_data_contact_detect(mxs_phy))
return chgr_type;
Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are
queue-4.15/usb-phy-mxs-fix-null-pointer-dereference-on-i.mx23-28.patch
This is a note to let you know that I've just added the patch titled
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
to the 4.15-stable tree which can 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-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 46408ea558df13b110e0866b99624384a33bdeba Mon Sep 17 00:00:00 2001
From: AMAN DEEP <aman.deep(a)samsung.com>
Date: Thu, 8 Feb 2018 11:55:01 +0800
Subject: usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
From: AMAN DEEP <aman.deep(a)samsung.com>
commit 46408ea558df13b110e0866b99624384a33bdeba upstream.
There is a race condition between finish_unlinks->finish_urb() function
and usb_kill_urb() in ohci controller case. The finish_urb calls
spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
then if during this time, usb_kill_urb is called for another endpoint,
then new ed will be added to ed_rm_list at beginning for unlink, and
ed_rm_list will point to newly added.
When finish_urb() is completed in finish_unlinks() and ed->td_list
becomes empty as in below code (in finish_unlinks() function):
if (list_empty(&ed->td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;
ed->ed_next = NULL;
ed_schedule(ohci, ed);
}
The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
and previously added ed by usb_kill_urb will be left unreferenced by
ed_rm_list. This causes usb_kill_urb() hang forever waiting for
finish_unlink to remove added ed from ed_rm_list.
The main reason for hang in this race condtion is addition and removal
of ed from ed_rm_list in the beginning during usb_kill_urb and later
last* is modified in finish_unlinks().
As suggested by Alan Stern, the solution for proper handling of
ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
any URBs. Then at the end, we can add ed back to the list if necessary.
This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies")
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: <stable(a)vger.kernel.org>
Signed-off-by: Aman Deep <aman.deep(a)samsung.com>
Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/host/ohci-q.c b/drivers/usb/host/ohci-q.c
index b2ec8c399363..4ccb85a67bb3 100644
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -1019,6 +1019,8 @@ static void finish_unlinks(struct ohci_hcd *ohci)
* have modified this list. normally it's just prepending
* entries (which we'd ignore), but paranoia won't hurt.
*/
+ *last = ed->ed_next;
+ ed->ed_next = NULL;
modified = 0;
/* unlink urbs as requested, but rescan the list after
@@ -1077,21 +1079,22 @@ static void finish_unlinks(struct ohci_hcd *ohci)
goto rescan_this;
/*
- * If no TDs are queued, take ED off the ed_rm_list.
+ * If no TDs are queued, ED is now idle.
* Otherwise, if the HC is running, reschedule.
- * If not, leave it on the list for further dequeues.
+ * If the HC isn't running, add ED back to the
+ * start of the list for later processing.
*/
if (list_empty(&ed->td_list)) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed->state = ED_IDLE;
list_del(&ed->in_use_list);
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
- *last = ed->ed_next;
- ed->ed_next = NULL;
ed_schedule(ohci, ed);
} else {
- last = &ed->ed_next;
+ ed->ed_next = ohci->ed_rm_list;
+ ohci->ed_rm_list = ed;
+ /* Don't loop on the same ED */
+ if (last == &ohci->ed_rm_list)
+ last = &ed->ed_next;
}
if (modified)
Patches currently in stable-queue which might be from aman.deep(a)samsung.com are
queue-4.15/usb-ohci-proper-handling-of-ed_rm_list-to-handle-race-condition-between-usb_kill_urb-and-finish_unlinks.patch
This is a note to let you know that I've just added the patch titled
usb: ldusb: add PIDs for new CASSY devices supported by this driver
to the 4.15-stable tree which can 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-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 52ad2bd8918158266fc88a05f95429b56b6a33c5 Mon Sep 17 00:00:00 2001
From: Karsten Koop <kkoop(a)ld-didactic.de>
Date: Fri, 9 Feb 2018 09:12:06 +0000
Subject: usb: ldusb: add PIDs for new CASSY devices supported by this driver
From: Karsten Koop <kkoop(a)ld-didactic.de>
commit 52ad2bd8918158266fc88a05f95429b56b6a33c5 upstream.
This patch adds support for new CASSY devices to the ldusb driver. The
PIDs are also added to the ignore list in hid-quirks.
Signed-off-by: Karsten Koop <kkoop(a)ld-didactic.de>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
drivers/hid/hid-ids.h | 3 +++
drivers/usb/misc/ldusb.c | 6 ++++++
3 files changed, 12 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2721,6 +2721,9 @@ static const struct hid_device_id hid_ig
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -641,6 +641,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043
#define USB_DEVICE_ID_LD_JWM 0x1080
#define USB_DEVICE_ID_LD_DMMP 0x1081
#define USB_DEVICE_ID_LD_UMIP 0x1090
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -42,6 +42,9 @@
#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033 /* USB Product ID of Micro-CASSY Time (reserved) */
#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035 /* USB Product ID of Micro-CASSY Temperature */
#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038 /* USB Product ID of Micro-CASSY pH */
+#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040 /* USB Product ID of Power Analyser CASSY */
+#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042 /* USB Product ID of Converter Controller CASSY */
+#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043 /* USB Product ID of Machine Test CASSY */
#define USB_DEVICE_ID_LD_JWM 0x1080 /* USB Product ID of Joule and Wattmeter */
#define USB_DEVICE_ID_LD_DMMP 0x1081 /* USB Product ID of Digital Multimeter P (reserved) */
#define USB_DEVICE_ID_LD_UMIP 0x1090 /* USB Product ID of UMI P */
@@ -84,6 +87,9 @@ static const struct usb_device_id ld_usb
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) },
+ { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
Patches currently in stable-queue which might be from kkoop(a)ld-didactic.de are
queue-4.15/usb-ldusb-add-pids-for-new-cassy-devices-supported-by-this-driver.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Use config_ep_by_speed()
to the 4.15-stable tree which can 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-use-config_ep_by_speed.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 675272d092e4a5570bace92593776f7348daf4c5 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 23:58:20 -0800
Subject: usb: gadget: f_fs: Use config_ep_by_speed()
From: Jack Pham <jackp(a)codeaurora.org>
commit 675272d092e4a5570bace92593776f7348daf4c5 upstream.
In commit 2bfa0719ac2a ("usb: gadget: function: f_fs: pass
companion descriptor along") there is a pointer arithmetic
bug where the comp_desc is obtained as follows:
comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
USB_DT_ENDPOINT_SIZE);
Since ds is a pointer to usb_endpoint_descriptor, adding
7 to it ends up going out of bounds (7 * sizeof(struct
usb_endpoint_descriptor), which is actually 7*9 bytes) past
the SS descriptor. As a result the maxburst value will be
read incorrectly, and the UDC driver will also get a garbage
comp_desc (assuming it uses it).
Since Felipe wrote, "Eventually, f_fs.c should be converted
to use config_ep_by_speed() like all other functions, though",
let's finally do it. This allows the other usb_ep fields to
be properly populated, such as maxpacket and mult. It also
eliminates the awkward speed-based descriptor lookup since
config_ep_by_speed() does that already using the ones found
in struct usb_function.
Fixes: 2bfa0719ac2a ("usb: gadget: function: f_fs: pass companion descriptor along")
Cc: stable(a)vger.kernel.org
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 38 ++++++-------------------------------
1 file changed, 7 insertions(+), 31 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1852,44 +1852,20 @@ static int ffs_func_eps_enable(struct ff
spin_lock_irqsave(&func->ffs->eps_lock, flags);
while(count--) {
- struct usb_endpoint_descriptor *ds;
- struct usb_ss_ep_comp_descriptor *comp_desc = NULL;
- int needs_comp_desc = false;
- int desc_idx;
-
- if (ffs->gadget->speed == USB_SPEED_SUPER) {
- desc_idx = 2;
- needs_comp_desc = true;
- } else if (ffs->gadget->speed == USB_SPEED_HIGH)
- desc_idx = 1;
- else
- desc_idx = 0;
-
- /* fall-back to lower speed if desc missing for current speed */
- do {
- ds = ep->descs[desc_idx];
- } while (!ds && --desc_idx >= 0);
-
- if (!ds) {
- ret = -EINVAL;
- break;
- }
-
ep->ep->driver_data = ep;
- ep->ep->desc = ds;
- if (needs_comp_desc) {
- comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
- USB_DT_ENDPOINT_SIZE);
- ep->ep->maxburst = comp_desc->bMaxBurst + 1;
- ep->ep->comp_desc = comp_desc;
+ ret = config_ep_by_speed(func->gadget, &func->function, ep->ep);
+ if (ret) {
+ pr_err("%s: config_ep_by_speed(%s) returned %d\n",
+ __func__, ep->ep->name, ret);
+ break;
}
ret = usb_ep_enable(ep->ep);
if (likely(!ret)) {
epfile->ep = ep;
- epfile->in = usb_endpoint_dir_in(ds);
- epfile->isoc = usb_endpoint_xfer_isoc(ds);
+ epfile->in = usb_endpoint_dir_in(ep->ep->desc);
+ epfile->isoc = usb_endpoint_xfer_isoc(ep->ep->desc);
} else {
break;
}
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-4.15/usb-gadget-f_fs-use-config_ep_by_speed.patch
queue-4.15/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: host: ehci: use correct device pointer for dma ops
to the 4.15-stable tree which can 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-host-ehci-use-correct-device-pointer-for-dma-ops.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 02a10f061a3f8bca1b37332672f50a107198adbe Mon Sep 17 00:00:00 2001
From: Peter Chen <hzpeterchen(a)gmail.com>
Date: Thu, 1 Feb 2018 12:26:43 +0800
Subject: usb: host: ehci: use correct device pointer for dma ops
From: Peter Chen <hzpeterchen(a)gmail.com>
commit 02a10f061a3f8bca1b37332672f50a107198adbe upstream.
commit a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
converted to use hcd->self.sysdev for DMA operations instead of
hcd->self.controller, but forgot to do it for hcd test mode. Replace
the correct one in this commit.
Fixes: a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
Signed-off-by: Peter Chen <peter.chen(a)nxp.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/ehci-hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -774,12 +774,12 @@ static struct urb *request_single_step_s
atomic_inc(&urb->use_count);
atomic_inc(&urb->dev->urbnum);
urb->setup_dma = dma_map_single(
- hcd->self.controller,
+ hcd->self.sysdev,
urb->setup_packet,
sizeof(struct usb_ctrlrequest),
DMA_TO_DEVICE);
urb->transfer_dma = dma_map_single(
- hcd->self.controller,
+ hcd->self.sysdev,
urb->transfer_buffer,
urb->transfer_buffer_length,
DMA_FROM_DEVICE);
Patches currently in stable-queue which might be from hzpeterchen(a)gmail.com are
queue-4.15/usb-host-ehci-use-correct-device-pointer-for-dma-ops.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Process all descriptors during bind
to the 4.15-stable tree which can 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-process-all-descriptors-during-bind.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6cf439e0d37463e42784271179c8a308fd7493c6 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 00:11:53 -0800
Subject: usb: gadget: f_fs: Process all descriptors during bind
From: Jack Pham <jackp(a)codeaurora.org>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable(a)vger.kernel.org
Co-Developed-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2976,10 +2976,8 @@ static int _ffs_func_bind(struct usb_con
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
struct ffs_ep *eps_ptr;
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-4.15/usb-gadget-f_fs-use-config_ep_by_speed.patch
queue-4.15/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: ep0: Reset TRB counter for ep0 IN
to the 4.15-stable tree which can 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-dwc3-ep0-reset-trb-counter-for-ep0-in.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:27 -0800
Subject: usb: dwc3: ep0: Reset TRB counter for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit f035d139ffece7b6a7b8bfb17bd0ba715ee57a04 upstream.
DWC3 tracks TRB counter for each ep0 direction separately. In control
read transfer completion handler, the driver needs to reset the TRB
enqueue counter for ep0 IN direction. Currently the driver only resets
the TRB counter for control OUT endpoint. Check for the data direction
and properly reset the TRB counter from correct control endpoint.
Cc: stable(a)vger.kernel.org
Fixes: c2da2ff00606 ("usb: dwc3: ep0: don't use ep0in for transfers")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/ep0.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -858,7 +858,12 @@ static void dwc3_ep0_complete_data(struc
trb++;
trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
trace_dwc3_complete_trb(ep0, trb);
- ep0->trb_enqueue = 0;
+
+ if (r->direction)
+ dwc->eps[1]->trb_enqueue = 0;
+ else
+ dwc->eps[0]->trb_enqueue = 0;
+
dwc->ep0_bounced = false;
}
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.15/usb-dwc3-ep0-reset-trb-counter-for-ep0-in.patch
queue-4.15/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Set maxpacket size for ep0 IN
to the 4.15-stable tree which can 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-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6180026341e852a250e1f97ebdcf71684a3c81b9 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:05 -0800
Subject: usb: dwc3: gadget: Set maxpacket size for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
Cc: stable(a)vger.kernel.org
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2744,6 +2744,8 @@ static void dwc3_gadget_conndone_interru
break;
}
+ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket;
+
/* Enable USB2 LPM Capability */
if ((dwc->revision > DWC3_REVISION_194A) &&
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.15/usb-dwc3-ep0-reset-trb-counter-for-ep0-in.patch
queue-4.15/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
uapi-if_ether.h-move-__uapi_def_ethhdr-libc-define.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From da360299b6734135a5f66d7db458dcc7801c826a Mon Sep 17 00:00:00 2001
From: Hauke Mehrtens <hauke(a)hauke-m.de>
Date: Mon, 12 Feb 2018 23:59:51 +0100
Subject: uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define
From: Hauke Mehrtens <hauke(a)hauke-m.de>
commit da360299b6734135a5f66d7db458dcc7801c826a upstream.
This fixes a compile problem of some user space applications by not
including linux/libc-compat.h in uapi/if_ether.h.
linux/libc-compat.h checks which "features" the header files, included
from the libc, provide to make the Linux kernel uapi header files only
provide no conflicting structures and enums. If a user application mixes
kernel headers and libc headers it could happen that linux/libc-compat.h
gets included too early where not all other libc headers are included
yet. Then the linux/libc-compat.h would not prevent all the
redefinitions and we run into compile problems.
This patch removes the include of linux/libc-compat.h from
uapi/if_ether.h to fix the recently introduced case, but not all as this
is more or less impossible.
It is no problem to do the check directly in the if_ether.h file and not
in libc-compat.h as this does not need any fancy glibc header detection
as glibc never provided struct ethhdr and should define
__UAPI_DEF_ETHHDR by them self when they will provide this.
The following test program did not compile correctly any more:
#include <linux/if_ether.h>
#include <netinet/in.h>
#include <linux/in.h>
int main(void)
{
return 0;
}
Fixes: 6926e041a892 ("uapi/if_ether.h: prevent redefinition of struct ethhdr")
Reported-by: Guillaume Nault <g.nault(a)alphalink.fr>
Cc: <stable(a)vger.kernel.org> # 4.15
Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/if_ether.h | 6 +++++-
include/uapi/linux/libc-compat.h | 6 ------
2 files changed, 5 insertions(+), 7 deletions(-)
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -23,7 +23,6 @@
#define _UAPI_LINUX_IF_ETHER_H
#include <linux/types.h>
-#include <linux/libc-compat.h>
/*
* IEEE 802.3 Ethernet magic constants. The frame sizes omit the preamble
@@ -150,6 +149,11 @@
* This is an Ethernet frame header.
*/
+/* allow libcs like musl to deactivate this, glibc does not implement this. */
+#ifndef __UAPI_DEF_ETHHDR
+#define __UAPI_DEF_ETHHDR 1
+#endif
+
#if __UAPI_DEF_ETHHDR
struct ethhdr {
unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -264,10 +264,4 @@
#endif /* __GLIBC__ */
-/* Definitions for if_ether.h */
-/* allow libcs like musl to deactivate this, glibc does not implement this. */
-#ifndef __UAPI_DEF_ETHHDR
-#define __UAPI_DEF_ETHHDR 1
-#endif
-
#endif /* _UAPI_LIBC_COMPAT_H */
Patches currently in stable-queue which might be from hauke(a)hauke-m.de are
queue-4.15/uapi-if_ether.h-move-__uapi_def_ethhdr-libc-define.patch
This is a note to let you know that I've just added the patch titled
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c39813652700f3df552b6557530f1e5f782dbe2f Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Date: Tue, 23 Jan 2018 20:11:32 -0600
Subject: scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.
Cc: <stable(a)vger.kernel.org>
Reported-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -367,7 +367,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
Patches currently in stable-queue which might be from tyreld(a)linux.vnet.ibm.com are
queue-4.15/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
This is a note to let you know that I've just added the patch titled
Revert "usb: musb: host: don't start next rx urb if current one failed"
to the 4.15-stable tree which can 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-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 20 Feb 2018 07:31:35 -0600
Subject: Revert "usb: musb: host: don't start next rx urb if current one failed"
From: Bin Liu <b-liu(a)ti.com>
commit 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 upstream.
This reverts commit dbac5d07d13e330e6706813c9fde477140fb5d80.
commit dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")
along with commit b5801212229f ("usb: musb: host: clear rxcsr error bit if set")
try to solve the issue described in [1], but the latter alone is
sufficient, and the former causes the issue as in [2], so now revert it.
[1] https://marc.info/?l=linux-usb&m=146173995117456&w=2
[2] https://marc.info/?l=linux-usb&m=151689238420622&w=2
Cc: stable(a)vger.kernel.org # v4.7+
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/musb/musb_host.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -393,13 +393,7 @@ static void musb_advance_schedule(struct
}
}
- /*
- * The pipe must be broken if current urb->status is set, so don't
- * start next urb.
- * TODO: to minimize the risk of regression, only check urb->status
- * for RX, until we have a test case to understand the behavior of TX.
- */
- if ((!status || !is_in) && qh && qh->is_ready) {
+ if (qh != NULL && qh->is_ready) {
musb_dbg(musb, "... next ep%d %cX urb %p",
hw_ep->epnum, is_in ? 'R' : 'T', next_urb(qh));
musb_start_urb(musb, is_in, qh);
Patches currently in stable-queue which might be from b-liu(a)ti.com are
queue-4.15/revert-usb-musb-host-don-t-start-next-rx-urb-if-current-one-failed.patch
This is a note to let you know that I've just added the patch titled
RDMA/uverbs: Protect from races between lookup and destroy of uobjects
to the 4.15-stable tree which can 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-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6623e3e3cd78020016d3fa42555763178e94ab64 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Tue, 13 Feb 2018 12:18:37 +0200
Subject: RDMA/uverbs: Protect from races between lookup and destroy of uobjects
From: Leon Romanovsky <leonro(a)mellanox.com>
commit 6623e3e3cd78020016d3fa42555763178e94ab64 upstream.
The race is between lookup_get_idr_uobject and
uverbs_idr_remove_uobj -> uverbs_uobject_put.
We deliberately do not call sychronize_rcu after the idr_remove in
uverbs_idr_remove_uobj for performance reasons, instead we call
kfree_rcu() during uverbs_uobject_put.
However, this means we can obtain pointers to uobj's that have
already been released and must protect against krefing them
using kref_get_unless_zero.
==================================================================
BUG: KASAN: use-after-free in copy_ah_attr_from_uverbs.isra.2+0x860/0xa00
Read of size 4 at addr ffff88005fda1ac8 by task syz-executor2/441
CPU: 1 PID: 441 Comm: syz-executor2 Not tainted 4.15.0-rc2+ #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
dump_stack+0x8d/0xd4
print_address_description+0x73/0x290
kasan_report+0x25c/0x370
? copy_ah_attr_from_uverbs.isra.2+0x860/0xa00
copy_ah_attr_from_uverbs.isra.2+0x860/0xa00
? uverbs_try_lock_object+0x68/0xc0
? modify_qp.isra.7+0xdc4/0x10e0
modify_qp.isra.7+0xdc4/0x10e0
ib_uverbs_modify_qp+0xfe/0x170
? ib_uverbs_query_qp+0x970/0x970
? __lock_acquire+0xa11/0x1da0
ib_uverbs_write+0x55a/0xad0
? ib_uverbs_query_qp+0x970/0x970
? ib_uverbs_query_qp+0x970/0x970
? ib_uverbs_open+0x760/0x760
? futex_wake+0x147/0x410
? sched_clock_cpu+0x18/0x180
? check_prev_add+0x1680/0x1680
? do_futex+0x3b6/0xa30
? sched_clock_cpu+0x18/0x180
__vfs_write+0xf7/0x5c0
? ib_uverbs_open+0x760/0x760
? kernel_read+0x110/0x110
? lock_acquire+0x370/0x370
? __fget+0x264/0x3b0
vfs_write+0x18a/0x460
SyS_write+0xc7/0x1a0
? SyS_read+0x1a0/0x1a0
? trace_hardirqs_on_thunk+0x1a/0x1c
entry_SYSCALL_64_fastpath+0x18/0x85
RIP: 0033:0x448e29
RSP: 002b:00007f443fee0c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f443fee16bc RCX: 0000000000448e29
RDX: 0000000000000078 RSI: 00000000209f8000 RDI: 0000000000000012
RBP: 000000000070bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000008e98 R14: 00000000006ebf38 R15: 0000000000000000
Allocated by task 1:
kmem_cache_alloc_trace+0x16c/0x2f0
mlx5_alloc_cmd_msg+0x12e/0x670
cmd_exec+0x419/0x1810
mlx5_cmd_exec+0x40/0x70
mlx5_core_mad_ifc+0x187/0x220
mlx5_MAD_IFC+0xd7/0x1b0
mlx5_query_mad_ifc_gids+0x1f3/0x650
mlx5_ib_query_gid+0xa4/0xc0
ib_query_gid+0x152/0x1a0
ib_query_port+0x21e/0x290
mlx5_port_immutable+0x30f/0x490
ib_register_device+0x5dd/0x1130
mlx5_ib_add+0x3e7/0x700
mlx5_add_device+0x124/0x510
mlx5_register_interface+0x11f/0x1c0
mlx5_ib_init+0x56/0x61
do_one_initcall+0xa3/0x250
kernel_init_freeable+0x309/0x3b8
kernel_init+0x14/0x180
ret_from_fork+0x24/0x30
Freed by task 1:
kfree+0xeb/0x2f0
mlx5_free_cmd_msg+0xcd/0x140
cmd_exec+0xeba/0x1810
mlx5_cmd_exec+0x40/0x70
mlx5_core_mad_ifc+0x187/0x220
mlx5_MAD_IFC+0xd7/0x1b0
mlx5_query_mad_ifc_gids+0x1f3/0x650
mlx5_ib_query_gid+0xa4/0xc0
ib_query_gid+0x152/0x1a0
ib_query_port+0x21e/0x290
mlx5_port_immutable+0x30f/0x490
ib_register_device+0x5dd/0x1130
mlx5_ib_add+0x3e7/0x700
mlx5_add_device+0x124/0x510
mlx5_register_interface+0x11f/0x1c0
mlx5_ib_init+0x56/0x61
do_one_initcall+0xa3/0x250
kernel_init_freeable+0x309/0x3b8
kernel_init+0x14/0x180
ret_from_fork+0x24/0x30
The buggy address belongs to the object at ffff88005fda1ab0
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 24 bytes inside of
32-byte region [ffff88005fda1ab0, ffff88005fda1ad0)
The buggy address belongs to the page:
page:00000000d5655c19 count:1 mapcount:0 mapping: (null)
index:0xffff88005fda1fc0
flags: 0x4000000000000100(slab)
raw: 4000000000000100 0000000000000000 ffff88005fda1fc0 0000000180550008
raw: ffffea00017f6780 0000000400000004 ffff88006c803980 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88005fda1980: fc fc fb fb fb fb fc fc fb fb fb fb fc fc fb fb
ffff88005fda1a00: fb fb fc fc fb fb fb fb fc fc 00 00 00 00 fc fc
ffff88005fda1a80: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb
ffff88005fda1b00: fc fc 00 00 00 00 fc fc fb fb fb fb fc fc fb fb
ffff88005fda1b80: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc
==================================================================@
Cc: syzkaller <syzkaller(a)googlegroups.com>
Cc: <stable(a)vger.kernel.org> # 4.11
Fixes: 3832125624b7 ("IB/core: Add support for idr types")
Reported-by: Noa Osherovich <noaos(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/rdma_core.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -196,7 +196,15 @@ static struct ib_uobject *lookup_get_idr
goto free;
}
- uverbs_uobject_get(uobj);
+ /*
+ * The idr_find is guaranteed to return a pointer to something that
+ * isn't freed yet, or NULL, as the free after idr_remove goes through
+ * kfree_rcu(). However the object may still have been released and
+ * kfree() could be called at any time.
+ */
+ if (!kref_get_unless_zero(&uobj->ref))
+ uobj = ERR_PTR(-ENOENT);
+
free:
rcu_read_unlock();
return uobj;
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.15/rdma-uverbs-fix-bad-unlock-balance-in-ib_uverbs_close_xrcd.patch
queue-4.15/rdma-uverbs-fix-circular-locking-dependency.patch
queue-4.15/rdma-uverbs-sanitize-user-entered-port-numbers-prior-to-access-it.patch
queue-4.15/rdma-uverbs-protect-from-races-between-lookup-and-destroy-of-uobjects.patch
queue-4.15/rdma-uverbs-protect-from-command-mask-overflow.patch