This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: fix container_of member in dmatest_callback
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-dmatest-fix-container_of-member-in-dmatest_callback.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 66b3bd2356e0a1531c71a3dcf96944621e25c17c Mon Sep 17 00:00:00 2001
From: Yang Shunyong <shunyong.yang(a)hxt-semitech.com>
Date: Mon, 29 Jan 2018 14:40:11 +0800
Subject: dmaengine: dmatest: fix container_of member in dmatest_callback
From: Yang Shunyong <shunyong.yang(a)hxt-semitech.com>
commit 66b3bd2356e0a1531c71a3dcf96944621e25c17c upstream.
The type of arg passed to dmatest_callback is struct dmatest_done.
It refers to test_done in struct dmatest_thread, not done_wait.
Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
Signed-off-by: Yang Shunyong <shunyong.yang(a)hxt-semitech.com>
Acked-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -339,7 +339,7 @@ static void dmatest_callback(void *arg)
{
struct dmatest_done *done = arg;
struct dmatest_thread *thread =
- container_of(arg, struct dmatest_thread, done_wait);
+ container_of(done, struct dmatest_thread, test_done);
if (!thread->done) {
done->done = true;
wake_up_all(done->wait);
Patches currently in stable-queue which might be from shunyong.yang(a)hxt-semitech.com are
queue-4.9/dmaengine-dmatest-fix-container_of-member-in-dmatest_callback.patch
This is a note to let you know that I've just added the patch titled
CIFS: zero sensitive data when freeing
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:
cifs-zero-sensitive-data-when-freeing.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 97f4b7276b829a8927ac903a119bef2f963ccc58 Mon Sep 17 00:00:00 2001
From: Aurelien Aptel <aaptel(a)suse.com>
Date: Thu, 25 Jan 2018 15:59:39 +0100
Subject: CIFS: zero sensitive data when freeing
From: Aurelien Aptel <aaptel(a)suse.com>
commit 97f4b7276b829a8927ac903a119bef2f963ccc58 upstream.
also replaces memset()+kfree() by kzfree().
Signed-off-by: Aurelien Aptel <aaptel(a)suse.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Reviewed-by: Pavel Shilovsky <pshilov(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/cifsencrypt.c | 3 +--
fs/cifs/connect.c | 6 +++---
fs/cifs/misc.c | 14 ++++----------
3 files changed, 8 insertions(+), 15 deletions(-)
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -318,9 +318,8 @@ int calc_lanman_hash(const char *passwor
{
int i;
int rc;
- char password_with_pad[CIFS_ENCPWD_SIZE];
+ char password_with_pad[CIFS_ENCPWD_SIZE] = {0};
- memset(password_with_pad, 0, CIFS_ENCPWD_SIZE);
if (password)
strncpy(password_with_pad, password, CIFS_ENCPWD_SIZE);
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1667,7 +1667,7 @@ cifs_parse_mount_options(const char *mou
tmp_end++;
if (!(tmp_end < end && tmp_end[1] == delim)) {
/* No it is not. Set the password to NULL */
- kfree(vol->password);
+ kzfree(vol->password);
vol->password = NULL;
break;
}
@@ -1705,7 +1705,7 @@ cifs_parse_mount_options(const char *mou
options = end;
}
- kfree(vol->password);
+ kzfree(vol->password);
/* Now build new password string */
temp_len = strlen(value);
vol->password = kzalloc(temp_len+1, GFP_KERNEL);
@@ -4159,7 +4159,7 @@ cifs_construct_tcon(struct cifs_sb_info
reset_cifs_unix_caps(0, tcon, NULL, vol_info);
out:
kfree(vol_info->username);
- kfree(vol_info->password);
+ kzfree(vol_info->password);
kfree(vol_info);
return tcon;
--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -99,14 +99,11 @@ sesInfoFree(struct cifs_ses *buf_to_free
kfree(buf_to_free->serverOS);
kfree(buf_to_free->serverDomain);
kfree(buf_to_free->serverNOS);
- if (buf_to_free->password) {
- memset(buf_to_free->password, 0, strlen(buf_to_free->password));
- kfree(buf_to_free->password);
- }
+ kzfree(buf_to_free->password);
kfree(buf_to_free->user_name);
kfree(buf_to_free->domainName);
- kfree(buf_to_free->auth_key.response);
- kfree(buf_to_free);
+ kzfree(buf_to_free->auth_key.response);
+ kzfree(buf_to_free);
}
struct cifs_tcon *
@@ -137,10 +134,7 @@ tconInfoFree(struct cifs_tcon *buf_to_fr
}
atomic_dec(&tconInfoAllocCount);
kfree(buf_to_free->nativeFileSystem);
- if (buf_to_free->password) {
- memset(buf_to_free->password, 0, strlen(buf_to_free->password));
- kfree(buf_to_free->password);
- }
+ kzfree(buf_to_free->password);
kfree(buf_to_free);
}
Patches currently in stable-queue which might be from aaptel(a)suse.com are
queue-4.9/cifs-zero-sensitive-data-when-freeing.patch
This is a note to let you know that I've just added the patch titled
dccp: CVE-2017-8824: use-after-free in DCCP code
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:
dccp-cve-2017-8824-use-after-free-in-dccp-code.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 69c64866ce072dea1d1e59a0d61e0f66c0dffb76 Mon Sep 17 00:00:00 2001
From: Mohamed Ghannam <simo.ghannam(a)gmail.com>
Date: Tue, 5 Dec 2017 20:58:35 +0000
Subject: dccp: CVE-2017-8824: use-after-free in DCCP code
From: Mohamed Ghannam <simo.ghannam(a)gmail.com>
commit 69c64866ce072dea1d1e59a0d61e0f66c0dffb76 upstream.
Whenever the sock object is in DCCP_CLOSED state,
dccp_disconnect() must free dccps_hc_tx_ccid and
dccps_hc_rx_ccid and set to NULL.
Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/dccp/proto.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -259,6 +259,7 @@ int dccp_disconnect(struct sock *sk, int
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct inet_sock *inet = inet_sk(sk);
+ struct dccp_sock *dp = dccp_sk(sk);
int err = 0;
const int old_state = sk->sk_state;
@@ -278,6 +279,10 @@ int dccp_disconnect(struct sock *sk, int
sk->sk_err = ECONNRESET;
dccp_clear_xmit_timers(sk);
+ ccid_hc_rx_delete(dp->dccps_hc_rx_ccid, sk);
+ ccid_hc_tx_delete(dp->dccps_hc_tx_ccid, sk);
+ dp->dccps_hc_rx_ccid = NULL;
+ dp->dccps_hc_tx_ccid = NULL;
__skb_queue_purge(&sk->sk_receive_queue);
__skb_queue_purge(&sk->sk_write_queue);
Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are
queue-4.9/dccp-cve-2017-8824-use-after-free-in-dccp-code.patch
This is a note to let you know that I've just added the patch titled
cifs: Fix missing put_xid in cifs_file_strict_mmap
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:
cifs-fix-missing-put_xid-in-cifs_file_strict_mmap.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 f04a703c3d613845ae3141bfaf223489de8ab3eb Mon Sep 17 00:00:00 2001
From: Matthew Wilcox <mawilcox(a)microsoft.com>
Date: Fri, 15 Dec 2017 12:48:32 -0800
Subject: cifs: Fix missing put_xid in cifs_file_strict_mmap
From: Matthew Wilcox <mawilcox(a)microsoft.com>
commit f04a703c3d613845ae3141bfaf223489de8ab3eb upstream.
If cifs_zap_mapping() returned an error, we would return without putting
the xid that we got earlier. Restructure cifs_file_strict_mmap() and
cifs_file_mmap() to be more similar to each other and have a single
point of return that always puts the xid.
Signed-off-by: Matthew Wilcox <mawilcox(a)microsoft.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/file.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -3285,20 +3285,18 @@ static const struct vm_operations_struct
int cifs_file_strict_mmap(struct file *file, struct vm_area_struct *vma)
{
- int rc, xid;
+ int xid, rc = 0;
struct inode *inode = file_inode(file);
xid = get_xid();
- if (!CIFS_CACHE_READ(CIFS_I(inode))) {
+ if (!CIFS_CACHE_READ(CIFS_I(inode)))
rc = cifs_zap_mapping(inode);
- if (rc)
- return rc;
- }
-
- rc = generic_file_mmap(file, vma);
- if (rc == 0)
+ if (!rc)
+ rc = generic_file_mmap(file, vma);
+ if (!rc)
vma->vm_ops = &cifs_file_vm_ops;
+
free_xid(xid);
return rc;
}
@@ -3308,16 +3306,16 @@ int cifs_file_mmap(struct file *file, st
int rc, xid;
xid = get_xid();
+
rc = cifs_revalidate_file(file);
- if (rc) {
+ if (rc)
cifs_dbg(FYI, "Validation prior to mmap failed, error=%d\n",
rc);
- free_xid(xid);
- return rc;
- }
- rc = generic_file_mmap(file, vma);
- if (rc == 0)
+ if (!rc)
+ rc = generic_file_mmap(file, vma);
+ if (!rc)
vma->vm_ops = &cifs_file_vm_ops;
+
free_xid(xid);
return rc;
}
Patches currently in stable-queue which might be from mawilcox(a)microsoft.com are
queue-4.9/cifs-fix-missing-put_xid-in-cifs_file_strict_mmap.patch
This is a note to let you know that I've just added the patch titled
cifs: Fix autonegotiate security settings mismatch
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
cifs-fix-autonegotiate-security-settings-mismatch.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9aca7e454415f7878b28524e76bebe1170911a88 Mon Sep 17 00:00:00 2001
From: Daniel N Pettersson <danielnp(a)axis.com>
Date: Thu, 11 Jan 2018 16:00:12 +0100
Subject: cifs: Fix autonegotiate security settings mismatch
From: Daniel N Pettersson <danielnp(a)axis.com>
commit 9aca7e454415f7878b28524e76bebe1170911a88 upstream.
Autonegotiation gives a security settings mismatch error if the SMB
server selects an SMBv3 dialect that isn't SMB3.02. The exact error is
"protocol revalidation - security settings mismatch".
This can be tested using Samba v4.2 or by setting the global Samba
setting max protocol = SMB3_00.
The check that fails in smb3_validate_negotiate is the dialect
verification of the negotiate info response. This is because it tries
to verify against the protocol_id in the global smbdefault_values. The
protocol_id in smbdefault_values is SMB3.02.
In SMB2_negotiate the protocol_id in smbdefault_values isn't updated,
it is global so it probably shouldn't be, but server->dialect is.
This patch changes the check in smb3_validate_negotiate to use
server->dialect instead of server->vals->protocol_id. The patch works
with autonegotiate and when using a specific version in the vers mount
option.
Signed-off-by: Daniel N Pettersson <danielnp(a)axis.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/smb2pdu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -585,8 +585,7 @@ int smb3_validate_negotiate(const unsign
}
/* check validate negotiate info response matches what we got earlier */
- if (pneg_rsp->Dialect !=
- cpu_to_le16(tcon->ses->server->vals->protocol_id))
+ if (pneg_rsp->Dialect != cpu_to_le16(tcon->ses->server->dialect))
goto vneg_out;
if (pneg_rsp->SecurityMode != cpu_to_le16(tcon->ses->server->sec_mode))
Patches currently in stable-queue which might be from danielnp(a)axis.com are
queue-4.9/cifs-fix-autonegotiate-security-settings-mismatch.patch
Recently, we are seeing I/O hungup reports.
I don't know whether a regression introduced by commit 50816c48997af857
("sched/wait: Standardize internal naming of wait-queue entries") is relevant.
But shouldn't we backport commit c6b9d9a330290144 ("sched/wait: Fix
add_wait_queue() behavioral change") to 4.13+ kernels anyway?
This is a note to let you know that I've just added the patch titled
watchdog: gpio_wdt: set WDOG_HW_RUNNING in gpio_wdt_stop
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:
watchdog-gpio_wdt-set-wdog_hw_running-in-gpio_wdt_stop.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 bc137dfdbec27c0ec5731a89002daded4a4aa1ea Mon Sep 17 00:00:00 2001
From: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Date: Thu, 9 Nov 2017 14:39:55 +0100
Subject: watchdog: gpio_wdt: set WDOG_HW_RUNNING in gpio_wdt_stop
From: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
commit bc137dfdbec27c0ec5731a89002daded4a4aa1ea upstream.
The first patch above (https://patchwork.kernel.org/patch/9970181/)
makes the oops go away, but it just papers over the problem. The real
problem is that the watchdog core clears WDOG_HW_RUNNING in
watchdog_stop, and the gpio driver fails to set it in its stop
function when it doesn't actually stop it. This means that the core
doesn't know that it now has responsibility for petting the device, in
turn causing the device to reset the system (I hadn't noticed this
because the board I'm working on has that reset logic disabled).
How about this (other drivers may of course have the same problem, I
haven't checked). One might say that ->stop should return an error
when the device can't be stopped, but OTOH this brings parity between
a device without a ->stop method and a GPIO wd that has always-running
set. IOW, I think ->stop should only return an error when an actual
attempt to stop the hardware failed.
From: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
The watchdog framework clears WDOG_HW_RUNNING before calling
->stop. If the driver is unable to stop the device, it is supposed to
set that bit again so that the watchdog core takes care of sending
heart-beats while the device is not open from user-space. Update the
gpio_wdt driver to honour that contract (and get rid of the redundant
clearing of WDOG_HW_RUNNING).
Fixes: 3c10bbde10 ("watchdog: core: Clear WDOG_HW_RUNNING before calling the stop function")
Signed-off-by: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/watchdog/gpio_wdt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -80,7 +80,8 @@ static int gpio_wdt_stop(struct watchdog
if (!priv->always_running) {
gpio_wdt_disable(priv);
- clear_bit(WDOG_HW_RUNNING, &wdd->status);
+ } else {
+ set_bit(WDOG_HW_RUNNING, &wdd->status);
}
return 0;
Patches currently in stable-queue which might be from rasmus.villemoes(a)prevas.dk are
queue-4.14/watchdog-gpio_wdt-set-wdog_hw_running-in-gpio_wdt_stop.patch
This is a note to let you know that I've just added the patch titled
sched/wait: Fix add_wait_queue() behavioral change
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:
sched-wait-fix-add_wait_queue-behavioral-change.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 c6b9d9a33029014446bd9ed84c1688f6d3d4eab9 Mon Sep 17 00:00:00 2001
From: Omar Sandoval <osandov(a)fb.com>
Date: Tue, 5 Dec 2017 23:15:31 -0800
Subject: sched/wait: Fix add_wait_queue() behavioral change
From: Omar Sandoval <osandov(a)fb.com>
commit c6b9d9a33029014446bd9ed84c1688f6d3d4eab9 upstream.
The following cleanup commit:
50816c48997a ("sched/wait: Standardize internal naming of wait-queue entries")
... unintentionally changed the behavior of add_wait_queue() from
inserting the wait entry at the head of the wait queue to the tail
of the wait queue.
Beyond a negative performance impact this change in behavior
theoretically also breaks wait queues which mix exclusive and
non-exclusive waiters, as non-exclusive waiters will not be
woken up if they are queued behind enough exclusive waiters.
Signed-off-by: Omar Sandoval <osandov(a)fb.com>
Reviewed-by: Jens Axboe <axboe(a)kernel.dk>
Acked-by: Peter Zijlstra <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: kernel-team(a)fb.com
Fixes: ("sched/wait: Standardize internal naming of wait-queue entries")
Link: http://lkml.kernel.org/r/a16c8ccffd39bd08fdaa45a5192294c784b803a7.151254432…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/wait.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -27,7 +27,7 @@ void add_wait_queue(struct wait_queue_he
wq_entry->flags &= ~WQ_FLAG_EXCLUSIVE;
spin_lock_irqsave(&wq_head->lock, flags);
- __add_wait_queue_entry_tail(wq_head, wq_entry);
+ __add_wait_queue(wq_head, wq_entry);
spin_unlock_irqrestore(&wq_head->lock, flags);
}
EXPORT_SYMBOL(add_wait_queue);
Patches currently in stable-queue which might be from osandov(a)fb.com are
queue-4.14/sched-wait-fix-add_wait_queue-behavioral-change.patch
This is a note to let you know that I've just added the patch titled
sched/rt: Use container_of() to get root domain in rto_push_irq_work_func()
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:
sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.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 ad0f1d9d65938aec72a698116cd73a980916895e Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Tue, 23 Jan 2018 20:45:37 -0500
Subject: sched/rt: Use container_of() to get root domain in rto_push_irq_work_func()
From: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
commit ad0f1d9d65938aec72a698116cd73a980916895e upstream.
When the rto_push_irq_work_func() is called, it looks at the RT overloaded
bitmask in the root domain via the runqueue (rq->rd). The problem is that
during CPU up and down, nothing here stops rq->rd from changing between
taking the rq->rd->rto_lock and releasing it. That means the lock that is
released is not the same lock that was taken.
Instead of using this_rq()->rd to get the root domain, as the irq work is
part of the root domain, we can simply get the root domain from the irq work
that is passed to the routine:
container_of(work, struct root_domain, rto_push_work)
This keeps the root domain consistent.
Reported-by: Pavan Kondeti <pkondeti(a)codeaurora.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
Link: http://lkml.kernel.org/r/CAEU1=PkiHO35Dzna8EQqNSKW1fr1y1zRQ5y66X117MG06sQtN…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/rt.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1907,9 +1907,8 @@ static void push_rt_tasks(struct rq *rq)
* the rt_loop_next will cause the iterator to perform another scan.
*
*/
-static int rto_next_cpu(struct rq *rq)
+static int rto_next_cpu(struct root_domain *rd)
{
- struct root_domain *rd = rq->rd;
int next;
int cpu;
@@ -1985,7 +1984,7 @@ static void tell_cpu_to_push(struct rq *
* Otherwise it is finishing up and an ipi needs to be sent.
*/
if (rq->rd->rto_cpu < 0)
- cpu = rto_next_cpu(rq);
+ cpu = rto_next_cpu(rq->rd);
raw_spin_unlock(&rq->rd->rto_lock);
@@ -1998,6 +1997,8 @@ static void tell_cpu_to_push(struct rq *
/* Called from hardirq context */
void rto_push_irq_work_func(struct irq_work *work)
{
+ struct root_domain *rd =
+ container_of(work, struct root_domain, rto_push_work);
struct rq *rq;
int cpu;
@@ -2013,18 +2014,18 @@ void rto_push_irq_work_func(struct irq_w
raw_spin_unlock(&rq->lock);
}
- raw_spin_lock(&rq->rd->rto_lock);
+ raw_spin_lock(&rd->rto_lock);
/* Pass the IPI to the next rt overloaded queue */
- cpu = rto_next_cpu(rq);
+ cpu = rto_next_cpu(rd);
- raw_spin_unlock(&rq->rd->rto_lock);
+ raw_spin_unlock(&rd->rto_lock);
if (cpu < 0)
return;
/* Try the next RT overloaded CPU */
- irq_work_queue_on(&rq->rd->rto_push_work, cpu);
+ irq_work_queue_on(&rd->rto_push_work, cpu);
}
#endif /* HAVE_RT_PUSH_IPI */
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.14/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.14/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
This is a note to let you know that I've just added the patch titled
sched/rt: Up the root domain ref count when passing it around via IPIs
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:
sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.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 364f56653708ba8bcdefd4f0da2a42904baa8eeb Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Tue, 23 Jan 2018 20:45:38 -0500
Subject: sched/rt: Up the root domain ref count when passing it around via IPIs
From: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
commit 364f56653708ba8bcdefd4f0da2a42904baa8eeb upstream.
When issuing an IPI RT push, where an IPI is sent to each CPU that has more
than one RT task scheduled on it, it references the root domain's rto_mask,
that contains all the CPUs within the root domain that has more than one RT
task in the runable state. The problem is, after the IPIs are initiated, the
rq->lock is released. This means that the root domain that is associated to
the run queue could be freed while the IPIs are going around.
Add a sched_get_rd() and a sched_put_rd() that will increment and decrement
the root domain's ref count respectively. This way when initiating the IPIs,
the scheduler will up the root domain's ref count before releasing the
rq->lock, ensuring that the root domain does not go away until the IPI round
is complete.
Reported-by: Pavan Kondeti <pkondeti(a)codeaurora.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
Link: http://lkml.kernel.org/r/CAEU1=PkiHO35Dzna8EQqNSKW1fr1y1zRQ5y66X117MG06sQtN…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/rt.c | 9 +++++++--
kernel/sched/sched.h | 2 ++
kernel/sched/topology.c | 13 +++++++++++++
3 files changed, 22 insertions(+), 2 deletions(-)
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1990,8 +1990,11 @@ static void tell_cpu_to_push(struct rq *
rto_start_unlock(&rq->rd->rto_loop_start);
- if (cpu >= 0)
+ if (cpu >= 0) {
+ /* Make sure the rd does not get freed while pushing */
+ sched_get_rd(rq->rd);
irq_work_queue_on(&rq->rd->rto_push_work, cpu);
+ }
}
/* Called from hardirq context */
@@ -2021,8 +2024,10 @@ void rto_push_irq_work_func(struct irq_w
raw_spin_unlock(&rd->rto_lock);
- if (cpu < 0)
+ if (cpu < 0) {
+ sched_put_rd(rd);
return;
+ }
/* Try the next RT overloaded CPU */
irq_work_queue_on(&rd->rto_push_work, cpu);
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -661,6 +661,8 @@ extern struct mutex sched_domains_mutex;
extern void init_defrootdomain(void);
extern int sched_init_domains(const struct cpumask *cpu_map);
extern void rq_attach_root(struct rq *rq, struct root_domain *rd);
+extern void sched_get_rd(struct root_domain *rd);
+extern void sched_put_rd(struct root_domain *rd);
#ifdef HAVE_RT_PUSH_IPI
extern void rto_push_irq_work_func(struct irq_work *work);
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -258,6 +258,19 @@ void rq_attach_root(struct rq *rq, struc
call_rcu_sched(&old_rd->rcu, free_rootdomain);
}
+void sched_get_rd(struct root_domain *rd)
+{
+ atomic_inc(&rd->refcount);
+}
+
+void sched_put_rd(struct root_domain *rd)
+{
+ if (!atomic_dec_and_test(&rd->refcount))
+ return;
+
+ call_rcu_sched(&rd->rcu, free_rootdomain);
+}
+
static int init_rootdomain(struct root_domain *rd)
{
if (!zalloc_cpumask_var(&rd->span, GFP_KERNEL))
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.14/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.14/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
This is a note to let you know that I've just added the patch titled
powerpc/pseries: include linux/types.h in asm/hvcall.h
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:
powerpc-pseries-include-linux-types.h-in-asm-hvcall.h.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 1b689a95ce7427075f9ac9fb4aea1af530742b7f Mon Sep 17 00:00:00 2001
From: Michal Suchanek <msuchanek(a)suse.de>
Date: Mon, 15 Jan 2018 14:30:03 +0100
Subject: powerpc/pseries: include linux/types.h in asm/hvcall.h
From: Michal Suchanek <msuchanek(a)suse.de>
commit 1b689a95ce7427075f9ac9fb4aea1af530742b7f upstream.
Commit 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
settings") uses u64 in asm/hvcall.h without including linux/types.h
This breaks hvcall.h users that do not include the header themselves.
Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush settings")
Signed-off-by: Michal Suchanek <msuchanek(a)suse.de>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/hvcall.h | 1 +
1 file changed, 1 insertion(+)
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -353,6 +353,7 @@
#define PROC_TABLE_GTSE 0x01
#ifndef __ASSEMBLY__
+#include <linux/types.h>
/**
* plpar_hcall_norets: - Make a pseries hypervisor call with no return arguments
Patches currently in stable-queue which might be from msuchanek(a)suse.de are
queue-4.14/powerpc-pseries-include-linux-types.h-in-asm-hvcall.h.patch
This is a note to let you know that I've just added the patch titled
KVM MMU: check pending exception before injecting APF
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:
kvm-mmu-check-pending-exception-before-injecting-apf.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 2a266f23550be997d783f27e704b9b40c4010292 Mon Sep 17 00:00:00 2001
From: Haozhong Zhang <haozhong.zhang(a)intel.com>
Date: Wed, 10 Jan 2018 21:44:42 +0800
Subject: KVM MMU: check pending exception before injecting APF
From: Haozhong Zhang <haozhong.zhang(a)intel.com>
commit 2a266f23550be997d783f27e704b9b40c4010292 upstream.
For example, when two APF's for page ready happen after one exit and
the first one becomes pending, the second one will result in #DF.
Instead, just handle the second page fault synchronously.
Reported-by: Ross Zwisler <zwisler(a)gmail.com>
Message-ID: <CAOxpaSUBf8QoOZQ1p4KfUp0jq76OKfGY4Uxs-Gg8ngReD99xww(a)mail.gmail.com>
Reported-by: Alec Blayne <ab(a)tevsa.net>
Signed-off-by: Haozhong Zhang <haozhong.zhang(a)intel.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/mmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3784,7 +3784,8 @@ static int kvm_arch_setup_async_pf(struc
bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu)
{
if (unlikely(!lapic_in_kernel(vcpu) ||
- kvm_event_needs_reinjection(vcpu)))
+ kvm_event_needs_reinjection(vcpu) ||
+ vcpu->arch.exception.pending))
return false;
if (!vcpu->arch.apf.delivery_as_pf_vmexit && is_guest_mode(vcpu))
Patches currently in stable-queue which might be from haozhong.zhang(a)intel.com are
queue-4.14/kvm-mmu-check-pending-exception-before-injecting-apf.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Fix deadlock in i830_disable_pipe()
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-fix-deadlock-in-i830_disable_pipe.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 4488496d58200c7511842e049a4cc891d928da56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Wed, 29 Nov 2017 14:54:11 +0200
Subject: drm/i915: Fix deadlock in i830_disable_pipe()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
commit 4488496d58200c7511842e049a4cc891d928da56 upstream.
i830_disable_pipe() gets called from the power well code, and thus
we're already holding the power domain mutex. That means we can't
call plane->get_hw_state() as it will also try to grab the
same mutex and will thus deadlock.
Replace the assert_plane() calls (which calls ->get_hw_state()) with
just raw register reads in i830_disable_pipe(). As a bonus we can
now get a warning if plane C is enabled even though we don't even
expose it as a drm plane.
v2: Do a separate WARN_ON() for each plane (Chris)
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Fixes: d87ce7640295 ("drm/i915: Add .get_hw_state() method for planes")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129125411.29055-1-ville.…
(cherry picked from commit 5816d9cbc0a0fbf232fe297cefcb85361a3cde90)
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_display.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14717,8 +14717,11 @@ void i830_disable_pipe(struct drm_i915_p
DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n",
pipe_name(pipe));
- assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_A));
- assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_B));
+ WARN_ON(I915_READ(DSPCNTR(PLANE_A)) & DISPLAY_PLANE_ENABLE);
+ WARN_ON(I915_READ(DSPCNTR(PLANE_B)) & DISPLAY_PLANE_ENABLE);
+ WARN_ON(I915_READ(DSPCNTR(PLANE_C)) & DISPLAY_PLANE_ENABLE);
+ WARN_ON(I915_READ(CURCNTR(PIPE_A)) & CURSOR_MODE);
+ WARN_ON(I915_READ(CURCNTR(PIPE_B)) & CURSOR_MODE);
I915_WRITE(PIPECONF(pipe), 0);
POSTING_READ(PIPECONF(pipe));
Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are
queue-4.14/drm-i915-redo-plane-sanitation-during-readout.patch
queue-4.14/drm-i915-add-.get_hw_state-method-for-planes.patch
queue-4.14/drm-i915-fix-deadlock-in-i830_disable_pipe.patch
This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: fix container_of member in dmatest_callback
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:
dmaengine-dmatest-fix-container_of-member-in-dmatest_callback.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 66b3bd2356e0a1531c71a3dcf96944621e25c17c Mon Sep 17 00:00:00 2001
From: Yang Shunyong <shunyong.yang(a)hxt-semitech.com>
Date: Mon, 29 Jan 2018 14:40:11 +0800
Subject: dmaengine: dmatest: fix container_of member in dmatest_callback
From: Yang Shunyong <shunyong.yang(a)hxt-semitech.com>
commit 66b3bd2356e0a1531c71a3dcf96944621e25c17c upstream.
The type of arg passed to dmatest_callback is struct dmatest_done.
It refers to test_done in struct dmatest_thread, not done_wait.
Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
Signed-off-by: Yang Shunyong <shunyong.yang(a)hxt-semitech.com>
Acked-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -355,7 +355,7 @@ static void dmatest_callback(void *arg)
{
struct dmatest_done *done = arg;
struct dmatest_thread *thread =
- container_of(arg, struct dmatest_thread, done_wait);
+ container_of(done, struct dmatest_thread, test_done);
if (!thread->done) {
done->done = true;
wake_up_all(done->wait);
Patches currently in stable-queue which might be from shunyong.yang(a)hxt-semitech.com are
queue-4.14/dmaengine-dmatest-fix-container_of-member-in-dmatest_callback.patch
This is a note to let you know that I've just added the patch titled
dccp: CVE-2017-8824: use-after-free in DCCP code
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:
dccp-cve-2017-8824-use-after-free-in-dccp-code.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 69c64866ce072dea1d1e59a0d61e0f66c0dffb76 Mon Sep 17 00:00:00 2001
From: Mohamed Ghannam <simo.ghannam(a)gmail.com>
Date: Tue, 5 Dec 2017 20:58:35 +0000
Subject: dccp: CVE-2017-8824: use-after-free in DCCP code
From: Mohamed Ghannam <simo.ghannam(a)gmail.com>
commit 69c64866ce072dea1d1e59a0d61e0f66c0dffb76 upstream.
Whenever the sock object is in DCCP_CLOSED state,
dccp_disconnect() must free dccps_hc_tx_ccid and
dccps_hc_rx_ccid and set to NULL.
Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/dccp/proto.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -259,6 +259,7 @@ int dccp_disconnect(struct sock *sk, int
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct inet_sock *inet = inet_sk(sk);
+ struct dccp_sock *dp = dccp_sk(sk);
int err = 0;
const int old_state = sk->sk_state;
@@ -278,6 +279,10 @@ int dccp_disconnect(struct sock *sk, int
sk->sk_err = ECONNRESET;
dccp_clear_xmit_timers(sk);
+ ccid_hc_rx_delete(dp->dccps_hc_rx_ccid, sk);
+ ccid_hc_tx_delete(dp->dccps_hc_tx_ccid, sk);
+ dp->dccps_hc_rx_ccid = NULL;
+ dp->dccps_hc_tx_ccid = NULL;
__skb_queue_purge(&sk->sk_receive_queue);
__skb_queue_purge(&sk->sk_write_queue);
Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are
queue-4.14/dccp-cve-2017-8824-use-after-free-in-dccp-code.patch
This is a note to let you know that I've just added the patch titled
cpufreq: mediatek: add mediatek related projects into blacklist
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:
cpufreq-mediatek-add-mediatek-related-projects-into-blacklist.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 6066998cbd2b1012a8d5bc9a2957cfd0ad53150e Mon Sep 17 00:00:00 2001
From: Andrew-sh Cheng <andrew-sh.cheng(a)mediatek.com>
Date: Fri, 8 Dec 2017 14:07:56 +0800
Subject: cpufreq: mediatek: add mediatek related projects into blacklist
From: Andrew-sh Cheng <andrew-sh.cheng(a)mediatek.com>
commit 6066998cbd2b1012a8d5bc9a2957cfd0ad53150e upstream.
mediatek projects will use mediate-cpufreq.c as cpufreq driver,
instead of using cpufreq_dt.c
Add mediatek related projects into cpufreq-dt blacklist
Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng(a)mediatek.com>
Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -111,6 +111,14 @@ static const struct of_device_id blackli
{ .compatible = "marvell,armadaxp", },
+ { .compatible = "mediatek,mt2701", },
+ { .compatible = "mediatek,mt2712", },
+ { .compatible = "mediatek,mt7622", },
+ { .compatible = "mediatek,mt7623", },
+ { .compatible = "mediatek,mt817x", },
+ { .compatible = "mediatek,mt8173", },
+ { .compatible = "mediatek,mt8176", },
+
{ .compatible = "nvidia,tegra124", },
{ .compatible = "st,stih407", },
Patches currently in stable-queue which might be from andrew-sh.cheng(a)mediatek.com are
queue-4.14/cpufreq-mediatek-add-mediatek-related-projects-into-blacklist.patch
This is a note to let you know that I've just added the patch titled
CIFS: zero sensitive data when freeing
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:
cifs-zero-sensitive-data-when-freeing.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 97f4b7276b829a8927ac903a119bef2f963ccc58 Mon Sep 17 00:00:00 2001
From: Aurelien Aptel <aaptel(a)suse.com>
Date: Thu, 25 Jan 2018 15:59:39 +0100
Subject: CIFS: zero sensitive data when freeing
From: Aurelien Aptel <aaptel(a)suse.com>
commit 97f4b7276b829a8927ac903a119bef2f963ccc58 upstream.
also replaces memset()+kfree() by kzfree().
Signed-off-by: Aurelien Aptel <aaptel(a)suse.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Reviewed-by: Pavel Shilovsky <pshilov(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/cifsencrypt.c | 3 +--
fs/cifs/connect.c | 6 +++---
fs/cifs/misc.c | 14 ++++----------
3 files changed, 8 insertions(+), 15 deletions(-)
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -325,9 +325,8 @@ int calc_lanman_hash(const char *passwor
{
int i;
int rc;
- char password_with_pad[CIFS_ENCPWD_SIZE];
+ char password_with_pad[CIFS_ENCPWD_SIZE] = {0};
- memset(password_with_pad, 0, CIFS_ENCPWD_SIZE);
if (password)
strncpy(password_with_pad, password, CIFS_ENCPWD_SIZE);
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1707,7 +1707,7 @@ cifs_parse_mount_options(const char *mou
tmp_end++;
if (!(tmp_end < end && tmp_end[1] == delim)) {
/* No it is not. Set the password to NULL */
- kfree(vol->password);
+ kzfree(vol->password);
vol->password = NULL;
break;
}
@@ -1745,7 +1745,7 @@ cifs_parse_mount_options(const char *mou
options = end;
}
- kfree(vol->password);
+ kzfree(vol->password);
/* Now build new password string */
temp_len = strlen(value);
vol->password = kzalloc(temp_len+1, GFP_KERNEL);
@@ -4235,7 +4235,7 @@ cifs_construct_tcon(struct cifs_sb_info
reset_cifs_unix_caps(0, tcon, NULL, vol_info);
out:
kfree(vol_info->username);
- kfree(vol_info->password);
+ kzfree(vol_info->password);
kfree(vol_info);
return tcon;
--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -98,14 +98,11 @@ sesInfoFree(struct cifs_ses *buf_to_free
kfree(buf_to_free->serverOS);
kfree(buf_to_free->serverDomain);
kfree(buf_to_free->serverNOS);
- if (buf_to_free->password) {
- memset(buf_to_free->password, 0, strlen(buf_to_free->password));
- kfree(buf_to_free->password);
- }
+ kzfree(buf_to_free->password);
kfree(buf_to_free->user_name);
kfree(buf_to_free->domainName);
- kfree(buf_to_free->auth_key.response);
- kfree(buf_to_free);
+ kzfree(buf_to_free->auth_key.response);
+ kzfree(buf_to_free);
}
struct cifs_tcon *
@@ -136,10 +133,7 @@ tconInfoFree(struct cifs_tcon *buf_to_fr
}
atomic_dec(&tconInfoAllocCount);
kfree(buf_to_free->nativeFileSystem);
- if (buf_to_free->password) {
- memset(buf_to_free->password, 0, strlen(buf_to_free->password));
- kfree(buf_to_free->password);
- }
+ kzfree(buf_to_free->password);
kfree(buf_to_free);
}
Patches currently in stable-queue which might be from aaptel(a)suse.com are
queue-4.14/cifs-zero-sensitive-data-when-freeing.patch
This is a note to let you know that I've just added the patch titled
cifs: Fix autonegotiate security settings mismatch
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:
cifs-fix-autonegotiate-security-settings-mismatch.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 9aca7e454415f7878b28524e76bebe1170911a88 Mon Sep 17 00:00:00 2001
From: Daniel N Pettersson <danielnp(a)axis.com>
Date: Thu, 11 Jan 2018 16:00:12 +0100
Subject: cifs: Fix autonegotiate security settings mismatch
From: Daniel N Pettersson <danielnp(a)axis.com>
commit 9aca7e454415f7878b28524e76bebe1170911a88 upstream.
Autonegotiation gives a security settings mismatch error if the SMB
server selects an SMBv3 dialect that isn't SMB3.02. The exact error is
"protocol revalidation - security settings mismatch".
This can be tested using Samba v4.2 or by setting the global Samba
setting max protocol = SMB3_00.
The check that fails in smb3_validate_negotiate is the dialect
verification of the negotiate info response. This is because it tries
to verify against the protocol_id in the global smbdefault_values. The
protocol_id in smbdefault_values is SMB3.02.
In SMB2_negotiate the protocol_id in smbdefault_values isn't updated,
it is global so it probably shouldn't be, but server->dialect is.
This patch changes the check in smb3_validate_negotiate to use
server->dialect instead of server->vals->protocol_id. The patch works
with autonegotiate and when using a specific version in the vers mount
option.
Signed-off-by: Daniel N Pettersson <danielnp(a)axis.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/smb2pdu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -733,8 +733,7 @@ int smb3_validate_negotiate(const unsign
}
/* check validate negotiate info response matches what we got earlier */
- if (pneg_rsp->Dialect !=
- cpu_to_le16(tcon->ses->server->vals->protocol_id))
+ if (pneg_rsp->Dialect != cpu_to_le16(tcon->ses->server->dialect))
goto vneg_out;
if (pneg_rsp->SecurityMode != cpu_to_le16(tcon->ses->server->sec_mode))
Patches currently in stable-queue which might be from danielnp(a)axis.com are
queue-4.14/cifs-fix-autonegotiate-security-settings-mismatch.patch
This is a note to let you know that I've just added the patch titled
cifs: Fix missing put_xid in cifs_file_strict_mmap
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:
cifs-fix-missing-put_xid-in-cifs_file_strict_mmap.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 f04a703c3d613845ae3141bfaf223489de8ab3eb Mon Sep 17 00:00:00 2001
From: Matthew Wilcox <mawilcox(a)microsoft.com>
Date: Fri, 15 Dec 2017 12:48:32 -0800
Subject: cifs: Fix missing put_xid in cifs_file_strict_mmap
From: Matthew Wilcox <mawilcox(a)microsoft.com>
commit f04a703c3d613845ae3141bfaf223489de8ab3eb upstream.
If cifs_zap_mapping() returned an error, we would return without putting
the xid that we got earlier. Restructure cifs_file_strict_mmap() and
cifs_file_mmap() to be more similar to each other and have a single
point of return that always puts the xid.
Signed-off-by: Matthew Wilcox <mawilcox(a)microsoft.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/file.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -3488,20 +3488,18 @@ static const struct vm_operations_struct
int cifs_file_strict_mmap(struct file *file, struct vm_area_struct *vma)
{
- int rc, xid;
+ int xid, rc = 0;
struct inode *inode = file_inode(file);
xid = get_xid();
- if (!CIFS_CACHE_READ(CIFS_I(inode))) {
+ if (!CIFS_CACHE_READ(CIFS_I(inode)))
rc = cifs_zap_mapping(inode);
- if (rc)
- return rc;
- }
-
- rc = generic_file_mmap(file, vma);
- if (rc == 0)
+ if (!rc)
+ rc = generic_file_mmap(file, vma);
+ if (!rc)
vma->vm_ops = &cifs_file_vm_ops;
+
free_xid(xid);
return rc;
}
@@ -3511,16 +3509,16 @@ int cifs_file_mmap(struct file *file, st
int rc, xid;
xid = get_xid();
+
rc = cifs_revalidate_file(file);
- if (rc) {
+ if (rc)
cifs_dbg(FYI, "Validation prior to mmap failed, error=%d\n",
rc);
- free_xid(xid);
- return rc;
- }
- rc = generic_file_mmap(file, vma);
- if (rc == 0)
+ if (!rc)
+ rc = generic_file_mmap(file, vma);
+ if (!rc)
vma->vm_ops = &cifs_file_vm_ops;
+
free_xid(xid);
return rc;
}
Patches currently in stable-queue which might be from mawilcox(a)microsoft.com are
queue-4.14/cifs-fix-missing-put_xid-in-cifs_file_strict_mmap.patch
This is a note to let you know that I've just added the patch titled
arm64: Define cputype macros for Falkor CPU
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:
arm64-define-cputype-macros-for-falkor-cpu.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 c622cc013cece073722592cff1ac6643a33b1622 Mon Sep 17 00:00:00 2001
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Mon, 11 Dec 2017 16:42:31 -0600
Subject: arm64: Define cputype macros for Falkor CPU
From: Shanker Donthineni <shankerd(a)codeaurora.org>
commit c622cc013cece073722592cff1ac6643a33b1622 upstream.
Add cputype definition macros for Qualcomm Datacenter Technologies
Falkor CPU in cputype.h. It's unfortunate that the first revision
of the Falkor CPU used the wrong part number 0x800, got fixed in v2
chip with part number 0xC00, and would be used the same value for
future revisions.
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Cc: Timur Tabi <timur(a)codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -91,6 +91,7 @@
#define BRCM_CPU_PART_VULCAN 0x516
#define QCOM_CPU_PART_FALKOR_V1 0x800
+#define QCOM_CPU_PART_FALKOR 0xC00
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
@@ -99,6 +100,7 @@
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
#define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
+#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR)
#ifndef __ASSEMBLY__
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-4.14/arm64-add-software-workaround-for-falkor-erratum-1041.patch
queue-4.14/arm64-define-cputype-macros-for-falkor-cpu.patch
This is a note to let you know that I've just added the patch titled
arm64: Add software workaround for Falkor erratum 1041
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:
arm64-add-software-workaround-for-falkor-erratum-1041.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 932b50c7c1c65e6f23002e075b97ee083c4a9e71 Mon Sep 17 00:00:00 2001
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Mon, 11 Dec 2017 16:42:32 -0600
Subject: arm64: Add software workaround for Falkor erratum 1041
From: Shanker Donthineni <shankerd(a)codeaurora.org>
commit 932b50c7c1c65e6f23002e075b97ee083c4a9e71 upstream.
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter 4K and next 4K.
When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.
1) A System Error Interrupt (SEI) being raised by the Falkor core due
to the errant memory access attempting to access a region of memory
that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
memory. This behavior may only occur if the instruction cache is
disabled prior to or coincident with translation being changed from
enabled to disabled.
The conditions leading to this erratum will not occur when either of the
following occur:
1) A higher exception level disables translation of a lower exception level
(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0).
2) An exception level disabling its stage-1 translation if its stage-2
translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Cc: Timur Tabi <timur(a)codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 10 ++++++++++
arch/arm64/include/asm/assembler.h | 10 ++++++++++
arch/arm64/kernel/cpu-reset.S | 1 +
arch/arm64/kernel/efi-entry.S | 2 ++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/relocate_kernel.S | 1 +
arch/arm64/kvm/hyp-init.S | 1 +
8 files changed, 27 insertions(+)
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -74,3 +74,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
+| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -539,6 +539,16 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_E1041
+ bool "Falkor E1041: Speculative instruction fetches might cause errant memory access"
+ default y
+ help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
endmenu
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -499,4 +499,14 @@ alternative_else_nop_endif
#endif
.endm
+/**
+ * Errata workaround prior to disable MMU. Insert an ISB immediately prior
+ * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
+ */
+ .macro pre_disable_mmu_workaround
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
+ isb
+#endif
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -37,6 +37,7 @@ ENTRY(__cpu_soft_restart)
mrs x12, sctlr_el1
ldr x13, =SCTLR_ELx_FLAGS
bic x12, x12, x13
+ pre_disable_mmu_workaround
msr sctlr_el1, x12
isb
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -96,6 +96,7 @@ ENTRY(entry)
mrs x0, sctlr_el2
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
+ pre_disable_mmu_workaround
msr sctlr_el2, x0
isb
b 2f
@@ -103,6 +104,7 @@ ENTRY(entry)
mrs x0, sctlr_el1
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
+ pre_disable_mmu_workaround
msr sctlr_el1, x0
isb
2:
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -732,6 +732,7 @@ __primary_switch:
* to take into account by discarding the current kernel mapping and
* creating a new one.
*/
+ pre_disable_mmu_workaround
msr sctlr_el1, x20 // disable the MMU
isb
bl __create_page_tables // recreate kernel mapping
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -45,6 +45,7 @@ ENTRY(arm64_relocate_new_kernel)
mrs x0, sctlr_el2
ldr x1, =SCTLR_ELx_FLAGS
bic x0, x0, x1
+ pre_disable_mmu_workaround
msr sctlr_el2, x0
isb
1:
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -151,6 +151,7 @@ reset:
mrs x5, sctlr_el2
ldr x6, =SCTLR_ELx_FLAGS
bic x5, x5, x6 // Clear SCTL_M and etc
+ pre_disable_mmu_workaround
msr sctlr_el2, x5
isb
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-4.14/arm64-add-software-workaround-for-falkor-erratum-1041.patch
queue-4.14/arm64-define-cputype-macros-for-falkor-cpu.patch
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
These backports fix a plane related regression causing a corrupted
screen and bunch of WARNs from the kernel on some pre-i965 era
hardware.
Cc: <stable(a)vger.kernel.org> # 4.14
Ville Syrjälä (3):
drm/i915: Add .get_hw_state() method for planes
drm/i915: Redo plane sanitation during readout
drm/i915: Fix deadlock in i830_disable_pipe()
drivers/gpu/drm/i915/intel_display.c | 303 ++++++++++++++++++-----------------
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_sprite.c | 83 ++++++++++
3 files changed, 242 insertions(+), 146 deletions(-)
--
2.13.6
These two patches (back-ported from 4.15) implement a work-around for a
rare but serious erratum in Qualcomm Datacenter Technologies Falkor
cores.
One small merge conflict in arch/arm64/Kconfig was resolved when
back-porting patch #2.
P.S. I couldn't find any good examples of submitting a back-ported
patch with resolved merge conflicts to stable(a)vger.kernel.org, so I
hope I'm not forgetting anything.
Shanker Donthineni (2):
[for 4.14] arm64: Define cputype macros for Falkor CPU
[for 4.14] arm64: Add software workaround for Falkor erratum 1041
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 10 ++++++++++
arch/arm64/include/asm/assembler.h | 10 ++++++++++
arch/arm64/include/asm/cputype.h | 2 ++
arch/arm64/kernel/cpu-reset.S | 1 +
arch/arm64/kernel/efi-entry.S | 2 ++
arch/arm64/kernel/head.S | 1 +
arch/arm64/kernel/relocate_kernel.S | 1 +
arch/arm64/kvm/hyp-init.S | 1 +
9 files changed, 29 insertions(+)
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
From: Thomas Gleixner <tglx(a)linutronix.de>
commit cef31d9af908243421258f1df35a4a644604efbe upstream.
Please apply to 4.9-stable, 4.4-stable, and 3.18-stable.
timer_create() specifies via sigevent->sigev_notify the signal delivery for
the new timer. The valid modes are SIGEV_NONE, SIGEV_SIGNAL, SIGEV_THREAD
and (SIGEV_SIGNAL | SIGEV_THREAD_ID).
The sanity check in good_sigevent() is only checking the valid combination
for the SIGEV_THREAD_ID bit, i.e. SIGEV_SIGNAL, but if SIGEV_THREAD_ID is
not set it accepts any random value.
This has no real effects on the posix timer and signal delivery code, but
it affects show_timer() which handles the output of /proc/$PID/timers. That
function uses a string array to pretty print sigev_notify. The access to
that array has no bound checks, so random sigev_notify cause access beyond
the array bounds.
Add proper checks for the valid notify modes and remove the SIGEV_THREAD_ID
masking from various code pathes as SIGEV_NONE can never be set in
combination with SIGEV_THREAD_ID.
Reported-by: Eric Biggers <ebiggers3(a)gmail.com>
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: Alexey Dobriyan <adobriyan(a)gmail.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
kernel/time/posix-timers.c | 34 +++++++++++++++++++---------------
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index f2826c35e918..fc7c37ad90a0 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -507,17 +507,22 @@ static struct pid *good_sigevent(sigevent_t * event)
{
struct task_struct *rtn = current->group_leader;
- if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
- (!(rtn = find_task_by_vpid(event->sigev_notify_thread_id)) ||
- !same_thread_group(rtn, current) ||
- (event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL))
+ switch (event->sigev_notify) {
+ case SIGEV_SIGNAL | SIGEV_THREAD_ID:
+ rtn = find_task_by_vpid(event->sigev_notify_thread_id);
+ if (!rtn || !same_thread_group(rtn, current))
+ return NULL;
+ /* FALLTHRU */
+ case SIGEV_SIGNAL:
+ case SIGEV_THREAD:
+ if (event->sigev_signo <= 0 || event->sigev_signo > SIGRTMAX)
+ return NULL;
+ /* FALLTHRU */
+ case SIGEV_NONE:
+ return task_pid(rtn);
+ default:
return NULL;
-
- if (((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) &&
- ((event->sigev_signo <= 0) || (event->sigev_signo > SIGRTMAX)))
- return NULL;
-
- return task_pid(rtn);
+ }
}
void posix_timers_register_clock(const clockid_t clock_id,
@@ -745,8 +750,7 @@ common_timer_get(struct k_itimer *timr, struct itimerspec *cur_setting)
/* interval timer ? */
if (iv.tv64)
cur_setting->it_interval = ktime_to_timespec(iv);
- else if (!hrtimer_active(timer) &&
- (timr->it_sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE)
+ else if (!hrtimer_active(timer) && timr->it_sigev_notify != SIGEV_NONE)
return;
now = timer->base->get_time();
@@ -757,7 +761,7 @@ common_timer_get(struct k_itimer *timr, struct itimerspec *cur_setting)
* expiry is > now.
*/
if (iv.tv64 && (timr->it_requeue_pending & REQUEUE_PENDING ||
- (timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE))
+ timr->it_sigev_notify == SIGEV_NONE))
timr->it_overrun += (unsigned int) hrtimer_forward(timer, now, iv);
remaining = __hrtimer_expires_remaining_adjusted(timer, now);
@@ -767,7 +771,7 @@ common_timer_get(struct k_itimer *timr, struct itimerspec *cur_setting)
* A single shot SIGEV_NONE timer must return 0, when
* it is expired !
*/
- if ((timr->it_sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE)
+ if (timr->it_sigev_notify != SIGEV_NONE)
cur_setting->it_value.tv_nsec = 1;
} else
cur_setting->it_value = ktime_to_timespec(remaining);
@@ -865,7 +869,7 @@ common_timer_set(struct k_itimer *timr, int flags,
timr->it.real.interval = timespec_to_ktime(new_setting->it_interval);
/* SIGEV_NONE timers are not queued ! See common_timer_get */
- if (((timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE)) {
+ if (timr->it_sigev_notify == SIGEV_NONE) {
/* Setup correct expiry time for relative timers */
if (mode == HRTIMER_MODE_REL) {
hrtimer_add_expires(timer, timer->base->get_time());
--
2.16.0.rc1.238.g530d649a79-goog
Hi Greg, can you please apply commit dc3ee32e96d7 ("netfilter: nf_queue: Make
the queue_handler pernet") to 4.4-stable? syzbot is hitting the crash in
nfqnl_nf_hook_drop() by interrupting thread creation in pg_net_init(). An OOM
condition is not required, contrary to what is suggested by the original commit
message.
Thanks,
Eric
Hi stable maintainers
Can I get you to consider including
bc137dfdbec2 watchdog: gpio_wdt: set WDOG_HW_RUNNING in gpio_wdt_stop
in -stable? Without that, any (always-running) gpio watchdog effectively
fails to honour the magic close feature, causing an unexpected reset
shortly after userspace gracefully closes the device.
Anything containing 3c10bbde10 ("watchdog: core: Clear WDOG_HW_RUNNING
before calling the stop function") probably needs it (i.e. 4.8+), but at
the very least 4.14 and 4.15.
Rasmus
On Sat, 10 Feb 2018, Tobias Jakobi wrote:
> Hello,
>
> I noticed a compile error with a recent version (4.4.115) of the 4.4.y branch:
> arch/x86/mm/kaiser.c: In function ‘kaiser_init’:
> arch/x86/mm/kaiser.c:348:8: error: ‘vsyscall_pgprot’ undeclared (first use in
> this function)
>
> It seems like my combination of kernel options doesn't work for KAISER.
> X86_VSYSCALL_EMULATION is not set on my system, while LEGACY_VSYSCALL is set to
> NONE (LEGACY_VSYSCALL_NONE=y). I have managed to get things compiling again, by
> moving the 'extern unsigned long vsyscall_pgprot' outside of the preprocessor
> statement. This works for me, I guess because the code in question is never
> called during runtime anyway (vsyscall_enabled() always returns false).
>
> With best wishes,
> Tobias
Yes, sorry about that, thanks Tobias. Same error on 4.9 too.
Here's the patch that you correctly suggest, and it's good for both:
[PATCH 4.4 and 4.9] kaiser: fix compile error without vsyscall
Tobias noticed a compile error on 4.4.115, and it's the same on 4.9.80:
arch/x86/mm/kaiser.c: In function ‘kaiser_init’:
arch/x86/mm/kaiser.c:348:8: error: ‘vsyscall_pgprot’ undeclared
(first use in this function)
It seems like his combination of kernel options doesn't work for KAISER.
X86_VSYSCALL_EMULATION is not set on his system, while LEGACY_VSYSCALL
is set to NONE (LEGACY_VSYSCALL_NONE=y). He managed to get things
compiling again, by moving the 'extern unsigned long vsyscall_pgprot'
outside of the preprocessor statement. This works because the optimizer
removes that code (vsyscall_enabled() is always false) - and that's how
it was done in some older backports.
Reported-by: Tobias Jakobi <tjakobi(a)math.uni-bielefeld.de>
Signed-off-by: Hugh Dickins <hughd(a)google.com>
---
arch/x86/include/asm/vsyscall.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -13,7 +13,6 @@ extern void map_vsyscall(void);
*/
extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address);
extern bool vsyscall_enabled(void);
-extern unsigned long vsyscall_pgprot;
#else
static inline void map_vsyscall(void) {}
static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
@@ -22,5 +21,6 @@ static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
}
static inline bool vsyscall_enabled(void) { return false; }
#endif
+extern unsigned long vsyscall_pgprot;
#endif /* _ASM_X86_VSYSCALL_H */
On Mon, Feb 12, 2018 at 03:22:32PM +0000, James Hogan wrote:
> On Mon, Feb 12, 2018 at 05:08:10PM +0200, Kalle Valo wrote:
> > James Hogan <jhogan(a)kernel.org> writes:
> > > On Mon, Feb 05, 2018 at 01:23:31PM -0500, Adric Blake wrote:
> > >> I bisected to this "first bad commit:"
> > >>
> > >> commit 58eae1416b804d900014d84feadda7195007cc30
> > >> Author: James Hogan <jhogan(a)kernel.org>
> > >> Date: Mon Jan 15 21:17:14 2018 +0000
> > >>
> > >> ssb: Disable PCI host for PCI_DRIVERS_GENERIC
> > >
> > > Yes, really sorry about that and thanks for going to the effort of
> > > bisecting. There is a patch here:
> > > https://patchwork.kernel.org/patch/10185397/
> > >
> > > which is applied to linux-next as commit
> > > a9e6d44ddeccd3522670e641f1ed9b068e746ff7, and is tagged for stable,
> > > though I've just noticed the stable email address is incorrect... I'll
> > > make sure it gets applied to the 4.15 stable branch though as soon as
> > > I notice its merged.
> >
> > The commit is now in v4.16-rc1.
>
> Yes, thanks,
>
> Greg: Please can commit a9e6d44ddeccd3522670e641f1ed9b068e746ff7 ("ssb:
> Do not disable PCI host on non-Mips") be applied to 4.15 stable (the
> wrong stable email address was Cc'd in the commit message).
Now applied, thanks.
greg k-h
Please apply commit: 66b3bd2356e0a1531c71a3dcf96944621e25c17c (dmaengine:
dmatest: fix container_of member in dmatest_callback) to stable
This fixes a bug in dmatest that will cause the test to give a false negative.
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
Hi,
On Tue, Feb 13, 2018 at 3:32 PM, James Hogan <jhogan(a)kernel.org> wrote:
> On Tue, Feb 13, 2018 at 03:03:24PM +0100, Mathieu Malaterre wrote:
>> James,
>>
>> On Tue, Feb 13, 2018 at 2:38 PM, James Hogan <jhogan(a)kernel.org> wrote:
>> > On Tue, Feb 13, 2018 at 01:14:29PM +0100, Mathieu Malaterre wrote:
>> >> Could you please review the patch v3 ?
>> >
>> > Yes, looks good to me, and Ralf had applied to his test branch so I
>> > presume he's happy with it too. I'll apply for 4.16.
>>
>> Hum, just to be sure I understand the process. Which branch are you
>> talking about:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git
>
> I was referring to upstream-sfr.git branch=mips-next-test
> https://git.linux-mips.org/cgit/ralf/upstream-sfr.git/log/?h=mips-next-test
>
> (The mips-next branch there is what Ralf puts into linux-next)
>
> I've applied the patch to my mips-fixes branch here:
> git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git
>
> Sorry it seems a bit haphazard with multiple trees in use.
I see it now, sorry for the noise. I was not looking at the right location.
Anyway if that answer earlier question 4.11 should be correct, since I
asked Greg to not backport the earlier patch:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1505915.html
From: Eric Biggers <ebiggers(a)google.com>
Memslots must not overlap in guest physical memory, since otherwise some
guest physical addresses will not uniquely map to a memslot. Yet, the
overlap check in __kvm_set_memory_region() allows a memslot that
overlaps one of the "private" memslots, e.g. the memslot reserved for
the TSS on x86.
This seems to be a very old bug that was introduced years ago when
private memory slots were first added. It seems that later refactoring
incorrectly assumed this bug was intentional and preserved it.
Fix it by removing the loophole for private memslots, so we just check
for overlap against all memslots.
This bug was found by syzkaller, which used a memslot overlap to make
pte_list_remove() be called for the wrong memslot, hitting a BUG():
pte_list_remove: 000000007185ed42 0->BUG
kernel BUG at arch/x86/kvm/mmu.c:1209!
[...]
RIP: 0010:pte_list_remove+0x107/0x110 arch/x86/kvm/mmu.c:1208
[...]
Call Trace:
mmu_page_zap_pte+0x7e/0xd0 arch/x86/kvm/mmu.c:2499
kvm_mmu_page_unlink_children arch/x86/kvm/mmu.c:2521 [inline]
kvm_mmu_prepare_zap_page+0x4f/0x340 arch/x86/kvm/mmu.c:2565
kvm_zap_obsolete_pages arch/x86/kvm/mmu.c:5348 [inline]
kvm_mmu_invalidate_zap_all_pages+0xa6/0x100 arch/x86/kvm/mmu.c:5389
kvm_mmu_notifier_release+0x4f/0x80 arch/x86/kvm/../../../virt/kvm/kvm_main.c:468
__mmu_notifier_release+0x63/0x100 mm/mmu_notifier.c:75
mmu_notifier_release include/linux/mmu_notifier.h:244 [inline]
exit_mmap+0x160/0x170 mm/mmap.c:3009
__mmput kernel/fork.c:966 [inline]
mmput+0x44/0xd0 kernel/fork.c:987
exit_mm kernel/exit.c:544 [inline]
do_exit+0x24a/0xb50 kernel/exit.c:856
do_group_exit+0x34/0xb0 kernel/exit.c:972
SYSC_exit_group kernel/exit.c:983 [inline]
SyS_exit_group+0xb/0x10 kernel/exit.c:981
entry_SYSCALL_64_fastpath+0x1e/0x8b
Reproducer:
#include <fcntl.h>
#include <linux/kvm.h>
#include <sys/ioctl.h>
int main()
{
static char buf[4096*3] __attribute__((aligned(4096)));
int kvm, vm, cpu;
struct kvm_mp_state mp_state = { KVM_MP_STATE_SIPI_RECEIVED };
struct kvm_userspace_memory_region memreg = {
.memory_size = sizeof(buf),
.userspace_addr = (__u64)buf,
};
kvm = open("/dev/kvm", O_RDWR);
vm = ioctl(kvm, KVM_CREATE_VM, 0);
ioctl(vm, KVM_CREATE_IRQCHIP);
cpu = ioctl(vm, KVM_CREATE_VCPU, 0);
ioctl(cpu, KVM_SET_MP_STATE, &mp_state);
ioctl(vm, KVM_SET_TSS_ADDR, 0);
ioctl(cpu, KVM_RUN, 0);
ioctl(vm, KVM_SET_USER_MEMORY_REGION, &memreg);
}
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Fixes: e0d62c7f4860 ("KVM: Add kernel-internal memory slots")
Cc: <stable(a)vger.kernel.org> # v2.6.25+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
virt/kvm/kvm_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 210bf820385a..e536977e7b6d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -974,8 +974,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
/* Check for overlaps */
r = -EEXIST;
kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) {
- if ((slot->id >= KVM_USER_MEM_SLOTS) ||
- (slot->id == id))
+ if (slot->id == id)
continue;
if (!((base_gfn + npages <= slot->base_gfn) ||
(base_gfn >= slot->base_gfn + slot->npages)))
--
2.16.0
James,
On Tue, Feb 13, 2018 at 2:38 PM, James Hogan <jhogan(a)kernel.org> wrote:
> On Tue, Feb 13, 2018 at 01:14:29PM +0100, Mathieu Malaterre wrote:
>> On Thu, Feb 1, 2018 at 1:12 PM, Mathieu Malaterre <malat(a)debian.org> wrote:
>> > On Thu, Feb 1, 2018 at 12:37 PM, Marcin Nowakowski
>> > <marcin.nowakowski(a)mips.com> wrote:
>> >> Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a
>> >> fix to ensure that the memory range between PHYS_OFFSET and low memory
>> >> address specified by mem= cmdline argument is not later processed by
>> >> free_all_bootmem. This change was incorrect for systems where the
>> >> commandline specifies more than 1 mem argument, as it will cause all
>> >> memory between PHYS_OFFSET and each of the memory offsets to be marked
>> >> as reserved, which results in parts of the RAM marked as reserved
>> >> (Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0
>> >> mem=768M@0x30000000').
>> >>
>> >> Change the behaviour to ensure that only the range between PHYS_OFFSET
>> >> and the lowest start address of the memories is marked as protected.
>> >>
>> >> This change also ensures that the range is marked protected even if it's
>> >> only defined through the devicetree and not only via commandline
>> >> arguments.
>> >>
>> >> Reported-by: Mathieu Malaterre <mathieu.malaterre(a)gmail.com>
>> >> Signed-off-by: Marcin Nowakowski <marcin.nowakowski(a)mips.com>
>> >> Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
>> >> Cc: <stable(a)vger.kernel.org> # v4.11+
>> >> ---
>> >> v3: Update stable version, code cleanup as suggested by James Hogan
>> >> v2: Use updated email adress, add tag for stable.
>> >> ---
>> >> arch/mips/kernel/setup.c | 16 ++++++++++++----
>> >> 1 file changed, 12 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>> >> index 702c678de116..e4a1581ce822 100644
>> >> --- a/arch/mips/kernel/setup.c
>> >> +++ b/arch/mips/kernel/setup.c
>> >> @@ -375,6 +375,7 @@ static void __init bootmem_init(void)
>> >> unsigned long reserved_end;
>> >> unsigned long mapstart = ~0UL;
>> >> unsigned long bootmap_size;
>> >> + phys_addr_t ramstart = (phys_addr_t)ULLONG_MAX;
>> >> bool bootmap_valid = false;
>> >> int i;
>> >>
>> >> @@ -395,7 +396,8 @@ static void __init bootmem_init(void)
>> >> max_low_pfn = 0;
>> >>
>> >> /*
>> >> - * Find the highest page frame number we have available.
>> >> + * Find the highest page frame number we have available
>> >> + * and the lowest used RAM address
>> >> */
>> >> for (i = 0; i < boot_mem_map.nr_map; i++) {
>> >> unsigned long start, end;
>> >> @@ -407,6 +409,8 @@ static void __init bootmem_init(void)
>> >> end = PFN_DOWN(boot_mem_map.map[i].addr
>> >> + boot_mem_map.map[i].size);
>> >>
>> >> + ramstart = min(ramstart, boot_mem_map.map[i].addr);
>> >> +
>> >> #ifndef CONFIG_HIGHMEM
>> >> /*
>> >> * Skip highmem here so we get an accurate max_low_pfn if low
>> >> @@ -436,6 +440,13 @@ static void __init bootmem_init(void)
>> >> mapstart = max(reserved_end, start);
>> >> }
>> >>
>> >> + /*
>> >> + * Reserve any memory between the start of RAM and PHYS_OFFSET
>> >> + */
>> >> + if (ramstart > PHYS_OFFSET)
>> >> + add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
>> >> + BOOT_MEM_RESERVED);
>> >> +
>> >> if (min_low_pfn >= max_low_pfn)
>> >> panic("Incorrect memory mapping !!!");
>> >> if (min_low_pfn > ARCH_PFN_OFFSET) {
>> >> @@ -664,9 +675,6 @@ static int __init early_parse_mem(char *p)
>> >>
>> >> add_memory_region(start, size, BOOT_MEM_RAM);
>> >>
>> >> - if (start && start > PHYS_OFFSET)
>> >> - add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
>> >> - BOOT_MEM_RESERVED);
>> >> return 0;
>> >> }
>> >> early_param("mem", early_parse_mem);
>> >> --
>> >> 2.14.1
>> >>
>> >
>> > Looks good to me:
>> >
>> > $ cat /proc/cpuinfo
>> > system type : JZ4780
>> > machine : Creator CI20
>> > processor : 0
>> > cpu model : Ingenic JZRISC V4.15 FPU V0.0
>> > BogoMIPS : 956.00
>> > wait instruction : yes
>> > microsecond timers : no
>> > tlb_entries : 32
>> > extra interrupt vector : yes
>> > hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
>> > isa : mips1 mips2 mips32r1 mips32r2
>> > ASEs implemented :
>> > shadow register sets : 1
>> > kscratch registers : 0
>> > package : 0
>> > core : 0
>> > VCED exceptions : not available
>> > VCEI exceptions : not available
>> > $ uname -a
>> > Linux ci20 4.15.0+ #323 PREEMPT Thu Feb 1 13:08:11 CET 2018 mips GNU/Linux
>> >
>> > Tested-by: Mathieu Malaterre <malat(a)debian.org>
>> >
>> > Thanks
>>
>> Could you please review the patch v3 ?
>
> Yes, looks good to me, and Ralf had applied to his test branch so I
> presume he's happy with it too. I'll apply for 4.16.
Hum, just to be sure I understand the process. Which branch are you
talking about:
https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git
> Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") which
> this fixes was evidently requested to be backported to stable (unsure
> who by) and added to the 4.9 queue, but then this arose and it was
> removed until this fix is merged (see
> https://patchwork.linux-mips.org/patch/17268/).
>
> Anybody know how far back before 4.11 both of these patches should be
> applied to stable? If not I'll just leave it at 4.11 and if its
> important before then for kexec or whatever they can be requested again.
Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a
fix to ensure that the memory range between PHYS_OFFSET and low memory
address specified by mem= cmdline argument is not later processed by
free_all_bootmem. This change was incorrect for systems where the
commandline specifies more than 1 mem argument, as it will cause all
memory between PHYS_OFFSET and each of the memory offsets to be marked
as reserved, which results in parts of the RAM marked as reserved
(Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0
mem=768M@0x30000000').
Change the behaviour to ensure that only the range between PHYS_OFFSET
and the lowest start address of the memories is marked as protected.
This change also ensures that the range is marked protected even if it's
only defined through the devicetree and not only via commandline
arguments.
Reported-by: Mathieu Malaterre <mathieu.malaterre(a)gmail.com>
Signed-off-by: Marcin Nowakowski <marcin.nowakowski(a)mips.com>
Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
Cc: <stable(a)vger.kernel.org> # v4.11+
---
v3: Update stable version, code cleanup as suggested by James Hogan
v2: Use updated email adress, add tag for stable.
---
arch/mips/kernel/setup.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 702c678de116..e4a1581ce822 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -375,6 +375,7 @@ static void __init bootmem_init(void)
unsigned long reserved_end;
unsigned long mapstart = ~0UL;
unsigned long bootmap_size;
+ phys_addr_t ramstart = (phys_addr_t)ULLONG_MAX;
bool bootmap_valid = false;
int i;
@@ -395,7 +396,8 @@ static void __init bootmem_init(void)
max_low_pfn = 0;
/*
- * Find the highest page frame number we have available.
+ * Find the highest page frame number we have available
+ * and the lowest used RAM address
*/
for (i = 0; i < boot_mem_map.nr_map; i++) {
unsigned long start, end;
@@ -407,6 +409,8 @@ static void __init bootmem_init(void)
end = PFN_DOWN(boot_mem_map.map[i].addr
+ boot_mem_map.map[i].size);
+ ramstart = min(ramstart, boot_mem_map.map[i].addr);
+
#ifndef CONFIG_HIGHMEM
/*
* Skip highmem here so we get an accurate max_low_pfn if low
@@ -436,6 +440,13 @@ static void __init bootmem_init(void)
mapstart = max(reserved_end, start);
}
+ /*
+ * Reserve any memory between the start of RAM and PHYS_OFFSET
+ */
+ if (ramstart > PHYS_OFFSET)
+ add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
+ BOOT_MEM_RESERVED);
+
if (min_low_pfn >= max_low_pfn)
panic("Incorrect memory mapping !!!");
if (min_low_pfn > ARCH_PFN_OFFSET) {
@@ -664,9 +675,6 @@ static int __init early_parse_mem(char *p)
add_memory_region(start, size, BOOT_MEM_RAM);
- if (start && start > PHYS_OFFSET)
- add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
- BOOT_MEM_RESERVED);
return 0;
}
early_param("mem", early_parse_mem);
--
2.14.1
Commit-ID: 295cc7eb314eb3321fb6d67ca6f7305f5c50d10f
Gitweb: https://git.kernel.org/tip/295cc7eb314eb3321fb6d67ca6f7305f5c50d10f
Author: Masayoshi Mizuma <m.mizuma(a)jp.fujitsu.com>
AuthorDate: Thu, 8 Feb 2018 09:19:08 -0500
Committer: Ingo Molnar <mingo(a)kernel.org>
CommitDate: Tue, 13 Feb 2018 12:47:28 +0100
x86/smpboot: Fix uncore_pci_remove() indexing bug when hot-removing a physical CPU
When a physical CPU is hot-removed, the following warning messages
are shown while the uncore device is removed in uncore_pci_remove():
WARNING: CPU: 120 PID: 5 at arch/x86/events/intel/uncore.c:988
uncore_pci_remove+0xf1/0x110
...
CPU: 120 PID: 5 Comm: kworker/u1024:0 Not tainted 4.15.0-rc8 #1
Workqueue: kacpi_hotplug acpi_hotplug_work_fn
...
Call Trace:
pci_device_remove+0x36/0xb0
device_release_driver_internal+0x145/0x210
pci_stop_bus_device+0x76/0xa0
pci_stop_root_bus+0x44/0x60
acpi_pci_root_remove+0x1f/0x80
acpi_bus_trim+0x54/0x90
acpi_bus_trim+0x2e/0x90
acpi_device_hotplug+0x2bc/0x4b0
acpi_hotplug_work_fn+0x1a/0x30
process_one_work+0x141/0x340
worker_thread+0x47/0x3e0
kthread+0xf5/0x130
When uncore_pci_remove() runs, it tries to get the package ID to
clear the value of uncore_extra_pci_dev[].dev[] by using
topology_phys_to_logical_pkg(). The warning messesages are
shown because topology_phys_to_logical_pkg() returns -1.
arch/x86/events/intel/uncore.c:
static void uncore_pci_remove(struct pci_dev *pdev)
{
...
phys_id = uncore_pcibus_to_physid(pdev->bus);
...
pkg = topology_phys_to_logical_pkg(phys_id); // returns -1
for (i = 0; i < UNCORE_EXTRA_PCI_DEV_MAX; i++) {
if (uncore_extra_pci_dev[pkg].dev[i] == pdev) {
uncore_extra_pci_dev[pkg].dev[i] = NULL;
break;
}
}
WARN_ON_ONCE(i >= UNCORE_EXTRA_PCI_DEV_MAX); // <=========== HERE!!
topology_phys_to_logical_pkg() tries to find
cpuinfo_x86->phys_proc_id that matches the phys_pkg argument.
arch/x86/kernel/smpboot.c:
int topology_phys_to_logical_pkg(unsigned int phys_pkg)
{
int cpu;
for_each_possible_cpu(cpu) {
struct cpuinfo_x86 *c = &cpu_data(cpu);
if (c->initialized && c->phys_proc_id == phys_pkg)
return c->logical_proc_id;
}
return -1;
}
However, the phys_proc_id was already set to 0 by remove_siblinginfo()
when the CPU was offlined.
So, topology_phys_to_logical_pkg() cannot find the correct
logical_proc_id and always returns -1.
As the result, uncore_pci_remove() calls WARN_ON_ONCE() and the warning
messages are shown.
What is worse is that the bogus 'pkg' index results in two bugs:
- We dereference uncore_extra_pci_dev[] with a negative index
- We fail to clean up a stale pointer in uncore_extra_pci_dev[][]
To fix these bugs, remove the clearing of ->phys_proc_id from remove_siblinginfo().
This should not cause any problems, because ->phys_proc_id is not
used after it is hot-removed and it is re-set while hot-adding.
Signed-off-by: Masayoshi Mizuma <m.mizuma(a)jp.fujitsu.com>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: yasu.isimatu(a)gmail.com
Cc: <stable(a)vger.kernel.org>
Fixes: 30bb9811856f ("x86/topology: Avoid wasting 128k for package id array")
Link: http://lkml.kernel.org/r/ed738d54-0f01-b38b-b794-c31dc118c207@gmail.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
---
arch/x86/kernel/smpboot.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 6f27fac..cfc61e1 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1430,7 +1430,6 @@ static void remove_siblinginfo(int cpu)
cpumask_clear(cpu_llc_shared_mask(cpu));
cpumask_clear(topology_sibling_cpumask(cpu));
cpumask_clear(topology_core_cpumask(cpu));
- c->phys_proc_id = 0;
c->cpu_core_id = 0;
cpumask_clear_cpu(cpu, cpu_sibling_setup_mask);
recompute_smt_state();
This is a note to let you know that I've just added the patch titled
watchdog: indydog: Add dependency on SGI_HAS_INDYDOG
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:
watchdog-indydog-add-dependency-on-sgi_has_indydog.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 24f8d233074badd4c18e4dafd2fb97d65838afed Mon Sep 17 00:00:00 2001
From: Matt Redfearn <matt.redfearn(a)mips.com>
Date: Tue, 14 Nov 2017 10:52:54 +0000
Subject: watchdog: indydog: Add dependency on SGI_HAS_INDYDOG
From: Matt Redfearn <matt.redfearn(a)mips.com>
commit 24f8d233074badd4c18e4dafd2fb97d65838afed upstream.
Commit da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
enabled building the Indy watchdog driver when COMPILE_TEST is enabled.
However, the driver makes reference to symbols that are only defined for
certain platforms are selected in the config. These platforms select
SGI_HAS_INDYDOG. Without this, link time errors result, for example
when building a MIPS allyesconfig.
drivers/watchdog/indydog.o: In function `indydog_write':
indydog.c:(.text+0x18): undefined reference to `sgimc'
indydog.c:(.text+0x1c): undefined reference to `sgimc'
drivers/watchdog/indydog.o: In function `indydog_start':
indydog.c:(.text+0x54): undefined reference to `sgimc'
indydog.c:(.text+0x58): undefined reference to `sgimc'
drivers/watchdog/indydog.o: In function `indydog_stop':
indydog.c:(.text+0xa4): undefined reference to `sgimc'
drivers/watchdog/indydog.o:indydog.c:(.text+0xa8): more undefined
references to `sgimc' follow
make: *** [Makefile:1005: vmlinux] Error 1
Fix this by ensuring that CONFIG_INDIDOG can only be selected when the
necessary dependent platform symbols are built in.
Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Suggested-by: James Hogan <james.hogan(a)mips.com>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/watchdog/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1451,7 +1451,7 @@ config RC32434_WDT
config INDYDOG
tristate "Indy/I2 Hardware Watchdog"
- depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST)
+ depends on SGI_HAS_INDYDOG
help
Hardware driver for the Indy's/I2's watchdog. This is a
watchdog timer that will reboot the machine after a 60 second
Patches currently in stable-queue which might be from matt.redfearn(a)mips.com are
queue-4.14/watchdog-indydog-add-dependency-on-sgi_has_indydog.patch
This is a regression fix.
Before, to fix erratum AVR31, commit 522e66464467 ("x86/apic: Disable
I/O APIC before shutdown of the local APIC") moved lapic_shutdown()
calling after disable_IO_APIC() in reboot and kexec/kdump code path.
This introdued a regression. The root cause is that disable_IO_APIC()
not only clears IO_APIC, also restore boot irq mode by setting
LAPIC/APIC/IMCR, calling lapic_shutdown() after disable_IO_APIC() will
disable LAPIC and ruin the possible virtual wire mode setting which
the code has been trying to do all along.
The consequence is, in KVM guest kernel always prints warning as below
during kexec/kdump kernel boots up. That happened in setup_local_APIC()
since 'do { xxx } while (queued && max_loops > 0)' loop does not function
well any more if pending irq exists in APIC IRR after LAPIC is disabled.
[ 0.001000] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/apic/apic.c:1467 setup_local_APIC+0x228/0x330
[ 0.001000] Modules linked in:
[ 0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0-rc5+ #3
[ 0.001000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014
[ 0.001000] RIP: 0010:setup_local_APIC+0x228/0x330
[ 0.001000] RSP: 0000:ffffffffb6e03eb8 EFLAGS: 00010286
[ 0.001000] RAX: 0000009edb4c4d84 RBX: 0000000000000000 RCX: 00000000b099d800
[ 0.001000] RDX: 0000009e00000000 RSI: 0000000000000000 RDI: 0000000000000810
[ 0.001000] RBP: 0000000000000000 R08: ffffffffffffffff R09: 0000000000000001
[ 0.001000] R10: ffff98ce6a801c00 R11: 0761076d072f0776 R12: 0000000000000001
[ 0.001000] R13: 00000000000000f0 R14: 0000000000004000 R15: ffffffffffffc6ff
[ 0.001000] FS: 0000000000000000(0000) GS:ffff98ce6bc00000(0000) knlGS:0000000000000000
[ 0.001000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.001000] CR2: 00000000ffffffff CR3: 0000000022209000 CR4: 00000000000406b0
[ 0.001000] Call Trace:
[ 0.001000] apic_bsp_setup+0x56/0x74
[ 0.001000] x86_late_time_init+0x11/0x16
[ 0.001000] start_kernel+0x3c9/0x486
[ 0.001000] secondary_startup_64+0xa5/0xb0
[ 0.001000] Code: 00 85 c9 74 2d 0f 31 c1 e1 0a 48 c1 e2 20 41 89 cf 4c 03 7c 24 08 48 09 d0 49 29 c7 4c 89 3c 24 48 83 3c 24 00 0f 8f 8f fe ff
ff <0f> ff e9 10 ff ff ff 48 83 2c 24 01 eb e7 48 83 c4 18 5b 5d 41
[ 0.001000] ---[ end trace b88e71b9a6ebebdd ]---
[ 0.001000] masked ExtINT on CPU#0
To fix this, just break down disable_IO_APIC(), then call
clear_IO_APIC() to stop IO_APIC where disable_IO_APIC() was called,
and call restore_boot_irq_mode() to restore boot irq mode before
reboot or kexec/kdump jump.
As for KEXEC_JUMP, it's a little different then reboot and kexec/kdump.
It doesn't call lapic_shutdown() before jump, so is not impacted by
commit 522e66464467. Here in order to keep it the same as the old code,
replace the old disable_IO_APIC() with clear_IO_APIC() and
restore_boot_irq_mode().
Signed-off-by: Baoquan He <bhe(a)redhat.com>
Fixes: commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local APIC")
Cc: stable(a)vger.kernel.org
---
v4->v3:
Eric pointed out the change related to KEXEC_JUMP is not right.
Correct it.
Add Fixes tag and Cc to stable.
arch/x86/include/asm/io_apic.h | 1 +
arch/x86/kernel/apic/io_apic.c | 2 +-
arch/x86/kernel/crash.c | 3 ++-
arch/x86/kernel/machine_kexec_32.c | 3 ++-
arch/x86/kernel/machine_kexec_64.c | 3 ++-
arch/x86/kernel/reboot.c | 3 ++-
6 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 558d1a6a13ad..0fa95bfacb39 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -193,6 +193,7 @@ static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
extern void setup_IO_APIC(void);
extern void enable_IO_APIC(void);
extern void disable_IO_APIC(void);
+extern void clear_IO_APIC(void);
extern void restore_boot_irq_mode(void);
extern int IO_APIC_get_PCI_irq_vector(int bus, int devfn, int pin);
extern void print_IO_APICs(void);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 7b73b6b9b4b6..2d7cd2db77f5 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -587,7 +587,7 @@ static void clear_IO_APIC_pin(unsigned int apic, unsigned int pin)
mpc_ioapic_id(apic), pin);
}
-static void clear_IO_APIC (void)
+void clear_IO_APIC (void)
{
int apic, pin;
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 10e74d4778a1..1f6680427ff0 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -199,9 +199,10 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
#ifdef CONFIG_X86_IO_APIC
/* Prevent crash_kexec() from deadlocking on ioapic_lock. */
ioapic_zap_locks();
- disable_IO_APIC();
+ clear_IO_APIC();
#endif
lapic_shutdown();
+ restore_boot_irq_mode();
#ifdef CONFIG_HPET_TIMER
hpet_disable();
#endif
diff --git a/arch/x86/kernel/machine_kexec_32.c b/arch/x86/kernel/machine_kexec_32.c
index edfede768688..4cd79d88a4ac 100644
--- a/arch/x86/kernel/machine_kexec_32.c
+++ b/arch/x86/kernel/machine_kexec_32.c
@@ -199,7 +199,8 @@ void machine_kexec(struct kimage *image)
* one form or other. kexec jump path also need
* one.
*/
- disable_IO_APIC();
+ clear_IO_APIC();
+ restore_boot_irq_mode();
#endif
}
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 1f790cf9d38f..2ab14b9c1a89 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -297,7 +297,8 @@ void machine_kexec(struct kimage *image)
* one form or other. kexec jump path also need
* one.
*/
- disable_IO_APIC();
+ clear_IO_APIC();
+ restore_boot_irq_mode();
#endif
}
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 2126b9d27c34..725624b6c0c0 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -666,7 +666,7 @@ void native_machine_shutdown(void)
* Even without the erratum, it still makes sense to quiet IO APIC
* before disabling Local APIC.
*/
- disable_IO_APIC();
+ clear_IO_APIC();
#endif
#ifdef CONFIG_SMP
@@ -680,6 +680,7 @@ void native_machine_shutdown(void)
#endif
lapic_shutdown();
+ restore_boot_irq_mode();
#ifdef CONFIG_HPET_TIMER
hpet_disable();
--
2.13.6
This is the start of the stable review cycle for the 4.14.19 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 Sun Feb 11 13:39:12 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.19-rc1.gz
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.19-rc1
Dan Carpenter <dan.carpenter(a)oracle.com>
scsi: storvsc: missing error code in storvsc_probe()
Andrew Morton <akpm(a)linux-foundation.org>
kernel/exit.c: export abort() to modules
Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
arch: define weak abort()
Robert Baronescu <robert.baronescu(a)nxp.com>
crypto: tcrypt - fix S/G table for test_aead_speed()
Jesse Chan <jc(a)linux.com>
media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Jesse Chan <jc(a)linux.com>
media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION
Eric Dumazet <edumazet(a)google.com>
soreuseport: fix mem leak in reuseport_add_sock()
Martin KaFai Lau <kafai(a)fb.com>
ipv6: Fix SO_REUSEPORT UDP socket with implicit sk_ipv6only
Neal Cardwell <ncardwell(a)google.com>
tcp_bbr: fix pacing_gain to always be unity when using lt_bw
Jiri Pirko <jiri(a)mellanox.com>
rocker: fix possible null pointer dereference in rocker_router_fib_event_work
David Ahern <dsahern(a)gmail.com>
net: ipv6: send unsolicited NA after DAD
Roman Gushchin <guro(a)fb.com>
Revert "defer call to mem_cgroup_sk_alloc()"
Jason Wang <jasowang(a)redhat.com>
vhost_net: stop device during reset owner
Li RongQing <lirongqing(a)baidu.com>
tcp: release sk_frag.page in tcp_disconnect
Chunhao Lin <hau(a)realtek.com>
r8169: fix RTL8168EP take too long to complete driver initialization.
Kristian Evensen <kristian.evensen(a)gmail.com>
qmi_wwan: Add support for Quectel EP06
Junxiao Bi <junxiao.bi(a)oracle.com>
qlcnic: fix deadlock bug
Eric Dumazet <edumazet(a)google.com>
net: igmp: add a missing rcu locking section
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
ip6mr: fix stale iterator
Masahiro Yamada <yamada.masahiro(a)socionext.com>
kbuild: rpm-pkg: keep spec file until make mrproper
Masahiro Yamada <yamada.masahiro(a)socionext.com>
.gitignore: move *.dtb and *.dtb.S patterns to the top-level .gitignore
Masahiro Yamada <yamada.masahiro(a)socionext.com>
.gitignore: sort normal pattern rules alphabetically
-------------
Diffstat:
.gitignore | 49 ++++++++++++----------
Makefile | 4 +-
arch/arc/boot/.gitignore | 1 -
arch/arm/boot/.gitignore | 1 -
arch/arm/kernel/traps.c | 1 -
arch/arm64/boot/dts/.gitignore | 1 -
arch/m32r/kernel/traps.c | 1 -
arch/metag/boot/.gitignore | 1 -
arch/microblaze/boot/.gitignore | 1 -
arch/mips/boot/.gitignore | 1 -
arch/nios2/boot/.gitignore | 1 -
arch/powerpc/boot/.gitignore | 1 -
arch/unicore32/kernel/traps.c | 1 -
arch/xtensa/boot/.gitignore | 1 -
crypto/tcrypt.c | 6 ++-
.../media/platform/mtk-vcodec/mtk_vcodec_util.c | 3 ++
drivers/media/platform/soc_camera/soc_scale_crop.c | 4 ++
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 18 ++++----
drivers/net/ethernet/realtek/r8169.c | 4 +-
drivers/net/ethernet/rocker/rocker_main.c | 18 ++++----
drivers/net/usb/qmi_wwan.c | 1 +
drivers/of/unittest-data/.gitignore | 2 -
drivers/scsi/storvsc_drv.c | 4 +-
drivers/vhost/net.c | 1 +
kernel/exit.c | 9 ++++
mm/memcontrol.c | 14 +++++++
net/core/sock.c | 5 +--
net/core/sock_reuseport.c | 35 +++++++++-------
net/ipv4/igmp.c | 4 ++
net/ipv4/inet_connection_sock.c | 1 -
net/ipv4/tcp.c | 6 +++
net/ipv4/tcp_bbr.c | 6 +--
net/ipv6/addrconf.c | 30 +++++++++++--
net/ipv6/af_inet6.c | 11 +++--
net/ipv6/ip6mr.c | 1 +
net/ipv6/ndisc.c | 5 +++
scripts/package/Makefile | 4 +-
37 files changed, 164 insertions(+), 93 deletions(-)
This is the start of the stable review cycle for the 4.15.3 release.
There are 23 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 Sun Feb 11 13:39:20 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.3-rc1.gz
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.3-rc1
Robert Baronescu <robert.baronescu(a)nxp.com>
crypto: tcrypt - fix S/G table for test_aead_speed()
Masahiro Yamada <yamada.masahiro(a)socionext.com>
gpio: uniphier: fix mismatch between license text and MODULE_LICENSE
Jesse Chan <jc(a)linux.com>
media: tegra-cec: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Jesse Chan <jc(a)linux.com>
media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Jesse Chan <jc(a)linux.com>
media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION
Jiri Pirko <jiri(a)mellanox.com>
net: sched: fix use-after-free in tcf_block_put_ext
Cong Wang <xiyou.wangcong(a)gmail.com>
net_sched: get rid of rcu_barrier() in tcf_block_put_ext()
Eric Dumazet <edumazet(a)google.com>
soreuseport: fix mem leak in reuseport_add_sock()
Martin KaFai Lau <kafai(a)fb.com>
ipv6: Fix SO_REUSEPORT UDP socket with implicit sk_ipv6only
Paolo Abeni <pabeni(a)redhat.com>
cls_u32: add missing RCU annotation.
Neal Cardwell <ncardwell(a)google.com>
tcp_bbr: fix pacing_gain to always be unity when using lt_bw
Jiri Pirko <jiri(a)mellanox.com>
rocker: fix possible null pointer dereference in rocker_router_fib_event_work
David Ahern <dsahern(a)gmail.com>
net: ipv6: send unsolicited NA after DAD
Roman Gushchin <guro(a)fb.com>
Revert "defer call to mem_cgroup_sk_alloc()"
Wei Wang <weiwan(a)google.com>
ipv6: change route cache aging logic
Eric Dumazet <edumazet(a)google.com>
ipv6: addrconf: break critical section in addrconf_verify_rtnl()
Jason Wang <jasowang(a)redhat.com>
vhost_net: stop device during reset owner
Li RongQing <lirongqing(a)baidu.com>
tcp: release sk_frag.page in tcp_disconnect
Chunhao Lin <hau(a)realtek.com>
r8169: fix RTL8168EP take too long to complete driver initialization.
Kristian Evensen <kristian.evensen(a)gmail.com>
qmi_wwan: Add support for Quectel EP06
Junxiao Bi <junxiao.bi(a)oracle.com>
qlcnic: fix deadlock bug
Eric Dumazet <edumazet(a)google.com>
net: igmp: add a missing rcu locking section
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
ip6mr: fix stale iterator
-------------
Diffstat:
Makefile | 4 +--
crypto/tcrypt.c | 6 ++--
drivers/gpio/gpio-uniphier.c | 2 +-
.../media/platform/mtk-vcodec/mtk_vcodec_util.c | 3 ++
drivers/media/platform/soc_camera/soc_scale_crop.c | 4 +++
drivers/media/platform/tegra-cec/tegra_cec.c | 5 +++
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 18 +++++-----
drivers/net/ethernet/realtek/r8169.c | 4 +--
drivers/net/ethernet/rocker/rocker_main.c | 18 +++++-----
drivers/net/usb/qmi_wwan.c | 1 +
drivers/vhost/net.c | 1 +
include/net/sch_generic.h | 1 -
mm/memcontrol.c | 14 ++++++++
net/core/sock.c | 5 +--
net/core/sock_reuseport.c | 35 ++++++++++---------
net/ipv4/igmp.c | 4 +++
net/ipv4/inet_connection_sock.c | 1 -
net/ipv4/tcp.c | 6 ++++
net/ipv4/tcp_bbr.c | 6 ++--
net/ipv6/addrconf.c | 32 +++++++++++++++---
net/ipv6/af_inet6.c | 11 +++---
net/ipv6/ip6mr.c | 1 +
net/ipv6/ndisc.c | 5 +++
net/ipv6/route.c | 20 ++++++-----
net/sched/cls_api.c | 39 ++++++++--------------
net/sched/cls_u32.c | 12 ++++---
26 files changed, 163 insertions(+), 95 deletions(-)
This is a note to let you know that I've just added the patch titled
watchdog: indydog: Add dependency on SGI_HAS_INDYDOG
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:
watchdog-indydog-add-dependency-on-sgi_has_indydog.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 24f8d233074badd4c18e4dafd2fb97d65838afed Mon Sep 17 00:00:00 2001
From: Matt Redfearn <matt.redfearn(a)mips.com>
Date: Tue, 14 Nov 2017 10:52:54 +0000
Subject: watchdog: indydog: Add dependency on SGI_HAS_INDYDOG
From: Matt Redfearn <matt.redfearn(a)mips.com>
commit 24f8d233074badd4c18e4dafd2fb97d65838afed upstream.
Commit da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
enabled building the Indy watchdog driver when COMPILE_TEST is enabled.
However, the driver makes reference to symbols that are only defined for
certain platforms are selected in the config. These platforms select
SGI_HAS_INDYDOG. Without this, link time errors result, for example
when building a MIPS allyesconfig.
drivers/watchdog/indydog.o: In function `indydog_write':
indydog.c:(.text+0x18): undefined reference to `sgimc'
indydog.c:(.text+0x1c): undefined reference to `sgimc'
drivers/watchdog/indydog.o: In function `indydog_start':
indydog.c:(.text+0x54): undefined reference to `sgimc'
indydog.c:(.text+0x58): undefined reference to `sgimc'
drivers/watchdog/indydog.o: In function `indydog_stop':
indydog.c:(.text+0xa4): undefined reference to `sgimc'
drivers/watchdog/indydog.o:indydog.c:(.text+0xa8): more undefined
references to `sgimc' follow
make: *** [Makefile:1005: vmlinux] Error 1
Fix this by ensuring that CONFIG_INDIDOG can only be selected when the
necessary dependent platform symbols are built in.
Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Suggested-by: James Hogan <james.hogan(a)mips.com>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/watchdog/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1451,7 +1451,7 @@ config RC32434_WDT
config INDYDOG
tristate "Indy/I2 Hardware Watchdog"
- depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST)
+ depends on SGI_HAS_INDYDOG
help
Hardware driver for the Indy's/I2's watchdog. This is a
watchdog timer that will reboot the machine after a 60 second
Patches currently in stable-queue which might be from matt.redfearn(a)mips.com are
queue-4.15/watchdog-indydog-add-dependency-on-sgi_has_indydog.patch
The patch titled
Subject: vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
has been added to the -mm tree. Its filename is
vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/vmalloc-fix-__gfp_highmem-usage-fo…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/vmalloc-fix-__gfp_highmem-usage-fo…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Michal Hocko <mhocko(a)suse.com>
Subject: vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
Kai Heng Feng has noticed that BUG_ON(PageHighMem(pg)) triggers in
drivers/media/common/saa7146/saa7146_core.c since 19809c2da28a ("mm,
vmalloc: use __GFP_HIGHMEM implicitly"). saa7146_vmalloc_build_pgtable
uses vmalloc_32 and it is reasonable to expect that the resulting page is
not in highmem. The above commit aimed to add __GFP_HIGHMEM only for
those requests which do not specify any zone modifier gfp flag.
vmalloc_32 relies on GFP_VMALLOC32 which should do the right thing.
Except it has been missed that GFP_VMALLOC32 is an alias for GFP_KERNEL on
32b architectures. Thanks to Matthew to notice this.
Fix the problem by unconditionally setting GFP_DMA32 in GFP_VMALLOC32 for
!64b arches (as a bailout). This should do the right thing and use
ZONE_NORMAL which should be always below 4G on 32b systems.
Debugged by Matthew Wilcox.
Link: http://lkml.kernel.org/r/20180212095019.GX21609@dhcp22.suse.cz
Fixes: 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly”)
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Kai Heng Feng <kai.heng.feng(a)canonical.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/vmalloc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff -puN mm/vmalloc.c~vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems mm/vmalloc.c
--- a/mm/vmalloc.c~vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems
+++ a/mm/vmalloc.c
@@ -1947,7 +1947,11 @@ void *vmalloc_exec(unsigned long size)
#elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
#define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL
#else
-#define GFP_VMALLOC32 GFP_KERNEL
+/*
+ * 64b systems should always have either DMA or DMA32 zones. For others
+ * GFP_DMA32 should do the right thing and use the normal zone.
+ */
+#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
#endif
/**
_
Patches currently in -mm which might be from mhocko(a)suse.com are
vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2.patch
mm-introduce-map_fixed_safe.patch
fs-elf-drop-map_fixed-usage-from-elf_map.patch
mm-numa-rework-do_pages_move.patch
mm-migrate-remove-reason-argument-from-new_page_t.patch
mm-unclutter-thp-migration.patch
Some other drivers may be waiting for our extcon to show-up (exiting their
probe methods with -EPROBE_DEFER until we show up).
These drivers will typically get the cable state directly after getting
the extcon, this commit changes the int3496 code to process the id-pin
before registering the extcon, so that other drivers see the correct state
right away.
Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI ... driver")
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
Changes in v2:
-Add Fixes tag
Changes in v3:
-Fix oops on probe by scheduling the work too early
---
drivers/extcon/extcon-intel-int3496.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/extcon/extcon-intel-int3496.c b/drivers/extcon/extcon-intel-int3496.c
index c8691b5a9cb0..673bb26a9a2a 100644
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -131,11 +131,15 @@ static int int3496_probe(struct platform_device *pdev)
if (IS_ERR(data->gpio_usb_mux))
dev_info(dev, "can't request USB MUX GPIO\n");
- /* register extcon device */
data->edev = devm_extcon_dev_allocate(dev, int3496_cable);
if (IS_ERR(data->edev))
return -ENOMEM;
+ /* process id-pin first so that we start with the right status */
+ queue_delayed_work(system_wq, &data->work, 0);
+ flush_delayed_work(&data->work);
+
+ /* register extcon device */
ret = devm_extcon_dev_register(dev, data->edev);
if (ret < 0) {
dev_err(dev, "can't register extcon device: %d\n", ret);
@@ -153,9 +157,6 @@ static int int3496_probe(struct platform_device *pdev)
return ret;
}
- /* queue initial processing of id-pin */
- queue_delayed_work(system_wq, &data->work, 0);
-
platform_set_drvdata(pdev, data);
return 0;
--
2.14.3
With commit 3cf32d180227 ("mtd: nand: vf610: switch to
mtd_ooblayout_ops") the driver started to use the NAND cores
default large page ooblayout. However, shortly after commit
6a623e076944 ("mtd: nand: add ooblayout for old hamming layout")
changed the default layout to the old hamming layout, which is
not what vf610_nfc is using. Specify the default large page
layout explicitly.
Fixes: 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout")
Cc: <stable(a)vger.kernel.org> # v4.12+
Signed-off-by: Stefan Agner <stefan(a)agner.ch>
---
drivers/mtd/nand/vf610_nfc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 80d31a58e558..f367144f3c6f 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -752,10 +752,8 @@ static int vf610_nfc_probe(struct platform_device *pdev)
if (mtd->oobsize > 64)
mtd->oobsize = 64;
- /*
- * mtd->ecclayout is not specified here because we're using the
- * default large page ECC layout defined in NAND core.
- */
+ /* Use default large page ECC layout defined in NAND core */
+ mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
if (chip->ecc.strength == 32) {
nfc->ecc_mode = ECC_60_BYTE;
chip->ecc.bytes = 60;
--
2.16.1
Commit 41d600274fbf ("extcon: int3496: process id-pin first so that we
start with the right status") starts the work on the workqueue before
registration to make sure we've a valid cable state directly after
registration.
But that commit moves the queuing of the work to before we even alloc the
extcon, causing a NULL pointer deref in the worker.
This commit moves the queuing of the work to after we alloc the extcon,
fixing the NULL pointer deref.
Fixes: 41d600274fbf ("extcon: int3496: process id-pin first ...")
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/extcon/extcon-intel-int3496.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/extcon/extcon-intel-int3496.c b/drivers/extcon/extcon-intel-int3496.c
index b23ee9d993a3..673bb26a9a2a 100644
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -131,15 +131,15 @@ static int int3496_probe(struct platform_device *pdev)
if (IS_ERR(data->gpio_usb_mux))
dev_info(dev, "can't request USB MUX GPIO\n");
+ data->edev = devm_extcon_dev_allocate(dev, int3496_cable);
+ if (IS_ERR(data->edev))
+ return -ENOMEM;
+
/* process id-pin first so that we start with the right status */
queue_delayed_work(system_wq, &data->work, 0);
flush_delayed_work(&data->work);
/* register extcon device */
- data->edev = devm_extcon_dev_allocate(dev, int3496_cable);
- if (IS_ERR(data->edev))
- return -ENOMEM;
-
ret = devm_extcon_dev_register(dev, data->edev);
if (ret < 0) {
dev_err(dev, "can't register extcon device: %d\n", ret);
--
2.14.3
From: Huang Ying <huang.ying.caritas(a)gmail.com>
It was reported by Sergey Senozhatsky that if THP (Transparent Huge
Page) and frontswap (via zswap) are both enabled, when memory goes low
so that swap is triggered, segfault and memory corruption will occur
in random user space applications as follow,
kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
#0 0x00007fc08889ae0d _int_malloc (libc.so.6)
#1 0x00007fc08889c2f3 malloc (libc.so.6)
#2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
#3 0x0000560e6005e75c n/a (urxvt)
#4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
#5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
#6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
#7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
#8 0x0000560e6005cb55 ev_run (urxvt)
#9 0x0000560e6003b9b9 main (urxvt)
#10 0x00007fc08883af4a __libc_start_main (libc.so.6)
#11 0x0000560e6003f9da _start (urxvt)
After bisection, it was found the first bad commit is
bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped
out").
The root cause is as follow.
When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages
instead to improve the performance. But zswap (frontswap) will treat
THP as normal page, so only the head page is saved. After swapping
in, tail pages will not be restored to its original contents, so cause
the memory corruption in the applications.
This is fixed via splitting THP before writing the page to swap device
if frontswap is enabled. To deal with the situation where frontswap
is enabled at runtime, whether the page is THP is checked before using
frontswap during swapping out too.
Reported-and-tested-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Dan Streetman <ddstreet(a)ieee.org>
Cc: Seth Jennings <sjenning(a)redhat.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Shaohua Li <shli(a)kernel.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: stable(a)vger.kernel.org # 4.14
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Changelog:
v2:
- Move frontswap check into swapfile.c to avoid to make vmscan.c
depends on frontswap.
---
mm/page_io.c | 2 +-
mm/swapfile.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/page_io.c b/mm/page_io.c
index b41cf9644585..6dca817ae7a0 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -250,7 +250,7 @@ int swap_writepage(struct page *page, struct writeback_control *wbc)
unlock_page(page);
goto out;
}
- if (frontswap_store(page) == 0) {
+ if (!PageTransHuge(page) && frontswap_store(page) == 0) {
set_page_writeback(page);
unlock_page(page);
end_page_writeback(page);
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 006047b16814..0b7c7883ce64 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -934,6 +934,9 @@ int get_swap_pages(int n_goal, bool cluster, swp_entry_t swp_entries[])
/* Only single cluster request supported */
WARN_ON_ONCE(n_goal > 1 && cluster);
+ /* Frontswap doesn't support THP */
+ if (frontswap_enabled() && cluster)
+ goto noswap;
avail_pgs = atomic_long_read(&nr_swap_pages) / nr_pages;
if (avail_pgs <= 0)
--
2.15.1
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses") optimized xenbus concurrent accesses but in doing so
broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in
charge of xenbus message exchange with the correct header and body. Now,
after the mentioned commit the replies received by application will no
longer have the header req_id echoed back as it was on request (see
specification below for reference), because that particular field is being
overwritten by kernel.
struct xsd_sockmsg
{
uint32_t type; /* XS_??? */
uint32_t req_id;/* Request identifier, echoed in daemon's response. */
uint32_t tx_id; /* Transaction id (0 if not related to a transaction). */
uint32_t len; /* Length of data following this. */
/* Generally followed by nul-terminated string(s). */
};
Before there was only one request at a time so req_id could simply be
forwarded back and forth. To allow simultaneous requests we need a
different req_id for each message thus kernel keeps a monotonic increasing
counter for this field and is written on every request irrespective of
userspace value.
Forwarding again the req_id on userspace requests is not a solution because
we would open the possibility of userspace-generated req_id colliding with
kernel ones. So this patch instead takes another route which is to
artificially keep user req_id while keeping the xenbus logic as is. We do
that by saving the original req_id before xs_send(), use the private kernel
counter as req_id and then once reply comes and was validated, we restore
back the original req_id.
Cc: <stable(a)vger.kernel.org> # 4.11
Fixes: fd8aa9095a ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Reported-by: Bhavesh Davda <bhavesh.davda(a)oracle.com>
Signed-off-by: Joao Martins <joao.m.martins(a)oracle.com>
---
Here's a link to a unit test (https://pastebin.com/2q51j2sR) where req_id of
reply and response are being asserted each request. Without this patch
the assert will fail (e.g. try it with `./xswire_reqid_test name`). But
on <= v4.10 or >= v4.11 with the fix above, it will print domain name 10
times.
Changes since v1:
* Adjust commit message
(Comments from Juergen on IRC)
* Unilateraly save/restore req_id and remove xs_request_is_user()
* Initialize req_id for kernel callers
---
drivers/xen/xenbus/xenbus.h | 1 +
drivers/xen/xenbus/xenbus_comms.c | 1 +
drivers/xen/xenbus/xenbus_xs.c | 3 +++
3 files changed, 5 insertions(+)
diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 149c5e7efc89..092981171df1 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -76,6 +76,7 @@ struct xb_req_data {
struct list_head list;
wait_queue_head_t wq;
struct xsd_sockmsg msg;
+ uint32_t caller_req_id;
enum xsd_sockmsg_type type;
char *body;
const struct kvec *vec;
diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 5b081a01779d..d239fc3c5e3d 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -309,6 +309,7 @@ static int process_msg(void)
goto out;
if (req->state == xb_req_state_wait_reply) {
+ req->msg.req_id = req->caller_req_id;
req->msg.type = state.msg.type;
req->msg.len = state.msg.len;
req->body = state.body;
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 3e59590c7254..3f3b29398ab8 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -227,6 +227,8 @@ static void xs_send(struct xb_req_data *req, struct xsd_sockmsg *msg)
req->state = xb_req_state_queued;
init_waitqueue_head(&req->wq);
+ /* Save the caller req_id and restore it later in the reply */
+ req->caller_req_id = req->msg.req_id;
req->msg.req_id = xs_request_enter(req);
mutex_lock(&xb_write_mutex);
@@ -310,6 +312,7 @@ static void *xs_talkv(struct xenbus_transaction t,
req->num_vecs = num_vecs;
req->cb = xs_wake_up;
+ msg.req_id = 0;
msg.tx_id = t.id;
msg.type = type;
msg.len = 0;
--
2.11.0
From: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
In function xhci_stop, xhci_debugfs_exit called before xhci_mem_cleanup.
xhci_debugfs_exit removed the xhci debugfs root nodes, xhci_mem_cleanup
called function xhci_free_virt_devices_depth_first which in turn called
function xhci_debugfs_remove_slot.
Function xhci_debugfs_remove_slot removed the nodes for devices, the nodes
folders are sub folder of xhci debugfs.
It is unreasonable to remove xhci debugfs root folder before
xhci debugfs sub folder. Function xhci_mem_cleanup should be called
before function xhci_debugfs_exit.
Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver")
Cc: <stable(a)vger.kernel.org> # v4.15
Signed-off-by: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4adb6da..25d4b748 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -646,8 +646,6 @@ static void xhci_stop(struct usb_hcd *hcd)
return;
}
- xhci_debugfs_exit(xhci);
-
xhci_dbc_exit(xhci);
spin_lock_irq(&xhci->lock);
@@ -680,6 +678,7 @@ static void xhci_stop(struct usb_hcd *hcd)
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "cleaning up memory");
xhci_mem_cleanup(xhci);
+ xhci_debugfs_exit(xhci);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"xhci_stop completed - status = %x",
readl(&xhci->op_regs->status));
--
2.7.4
From: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
During system resume from hibernation, xhci host is reset, all the
nodes in devices folder are removed in xhci_mem_cleanup function.
Later nodes in /sys/kernel/debug/usb/xhci/* are created again in
function xhci_run, but the nodes already exist, so the nodes still
keep the old ones, finally device nodes in xhci debugfs folder
/sys/kernel/debug/usb/xhci/*/devices/* are disappeared.
This fix removed xhci debugfs nodes before the nodes are re-created,
so all the nodes in xhci debugfs can be re-created successfully.
Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver")
Cc: <stable(a)vger.kernel.org> # v4.15
Signed-off-by: Zhengjun Xing <zhengjun.xing(a)linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1eeb339..b01bd64 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1014,6 +1014,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
xhci_dbg(xhci, "cleaning up memory\n");
xhci_mem_cleanup(xhci);
+ xhci_debugfs_exit(xhci);
xhci_dbg(xhci, "xhci_stop completed - status = %x\n",
readl(&xhci->op_regs->status));
--
2.7.4
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().
Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement the active
transaction counter. But xenbus_transaction_end() has always counted the
transaction as finished regardless of the response.
The new behavior is that xenbus_dev_request_and_reply() and
xenbus_transaction_end() will always count the transaction as finished
regardless the response code (handled in xs_request_exit()).
But xenbus_dev_frontend tries to end a transaction on closing of the
device if the XS_TRANSACTION_END failed before. Trying to close the
transaction twice corrupts the reference count. So fix this by also
considering a transaction closed if we have sent XS_TRANSACTION_END once
regardless of the return code.
Cc: <stable(a)vger.kernel.org> # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Signed-off-by: Simon Gaiser <simon(a)invisiblethingslab.com>
---
drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index f3b089b7c0b6..d2edbc79384a 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -365,7 +365,7 @@ void xenbus_dev_queue_reply(struct xb_req_data *req)
if (WARN_ON(rc))
goto out;
}
- } else if (req->msg.type == XS_TRANSACTION_END) {
+ } else if (req->type == XS_TRANSACTION_END) {
trans = xenbus_get_transaction(u, req->msg.tx_id);
if (WARN_ON(!trans))
goto out;
--
2.15.1
From: Huang Ying <huang.ying.caritas(a)gmail.com>
It was reported by Sergey Senozhatsky that if THP (Transparent Huge
Page) and frontswap (via zswap) are both enabled, when memory goes low
so that swap is triggered, segfault and memory corruption will occur
in random user space applications as follow,
kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
#0 0x00007fc08889ae0d _int_malloc (libc.so.6)
#1 0x00007fc08889c2f3 malloc (libc.so.6)
#2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
#3 0x0000560e6005e75c n/a (urxvt)
#4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
#5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
#6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
#7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
#8 0x0000560e6005cb55 ev_run (urxvt)
#9 0x0000560e6003b9b9 main (urxvt)
#10 0x00007fc08883af4a __libc_start_main (libc.so.6)
#11 0x0000560e6003f9da _start (urxvt)
After bisection, it was found the first bad commit is
bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped
out").
The root cause is as follow.
When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages
instead to improve the performance. But zswap (frontswap) will treat
THP as normal page, so only the head page is saved. After swapping
in, tail pages will not be restored to its original contents, so cause
the memory corruption in the applications.
This is fixed via rejecting to save page in frontswap store functions
if the page is a THP. So that the THP will be swapped out to swap
device.
Another choice is to split THP if frontswap is enabled. But it is
found that the frontswap enabling isn't flexible. For example, if
CONFIG_ZSWAP=y (cannot be module), frontswap will be enabled even if
zswap itself isn't enabled.
Frontswap has multiple backends, to make it easy for one backend to
enable THP support, the THP checking is put in backend frontswap store
functions instead of the general interfaces.
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Reported-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Suggested-by: Minchan Kim <minchan(a)kernel.org> # put THP checking in backend
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Dan Streetman <ddstreet(a)ieee.org>
Cc: Seth Jennings <sjenning(a)redhat.com>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Shaohua Li <shli(a)kernel.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: stable(a)vger.kernel.org # 4.14
Changelog:
v3:
- Fix via checking THP in frontswap backend as suggested by Minchan.
v2:
- Move frontswap check into swapfile.c to avoid to make vmscan.c
depends on frontswap as suggested by Minchan.
---
drivers/xen/tmem.c | 4 ++++
mm/zswap.c | 6 ++++++
2 files changed, 10 insertions(+)
diff --git a/drivers/xen/tmem.c b/drivers/xen/tmem.c
index bf13d1ec51f3..04e7b3b29bac 100644
--- a/drivers/xen/tmem.c
+++ b/drivers/xen/tmem.c
@@ -284,6 +284,10 @@ static int tmem_frontswap_store(unsigned type, pgoff_t offset,
int pool = tmem_frontswap_poolid;
int ret;
+ /* THP isn't supported */
+ if (PageTransHuge(page))
+ return -1;
+
if (pool < 0)
return -1;
if (ind64 != ind)
diff --git a/mm/zswap.c b/mm/zswap.c
index c004aa4fd3f4..61a5c41972db 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -1007,6 +1007,12 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset,
u8 *src, *dst;
struct zswap_header zhdr = { .swpentry = swp_entry(type, offset) };
+ /* THP isn't supported */
+ if (PageTransHuge(page)) {
+ ret = -EINVAL;
+ goto reject;
+ }
+
if (!zswap_enabled || !tree) {
ret = -ENODEV;
goto reject;
--
2.15.1
Some other drivers may be waiting for our extcon to show-up (exiting their
probe methods with -EPROBE_DEFER until we show up).
These drivers will typically get the cable state directly after getting
the extcon, this commit changes the int3496 code to process the id-pin
before registering the extcon, so that other drivers see the correct state
right away.
Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI ... driver")
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/extcon/extcon-intel-int3496.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/extcon/extcon-intel-int3496.c b/drivers/extcon/extcon-intel-int3496.c
index c8691b5a9cb0..b23ee9d993a3 100644
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -131,6 +131,10 @@ static int int3496_probe(struct platform_device *pdev)
if (IS_ERR(data->gpio_usb_mux))
dev_info(dev, "can't request USB MUX GPIO\n");
+ /* process id-pin first so that we start with the right status */
+ queue_delayed_work(system_wq, &data->work, 0);
+ flush_delayed_work(&data->work);
+
/* register extcon device */
data->edev = devm_extcon_dev_allocate(dev, int3496_cable);
if (IS_ERR(data->edev))
@@ -153,9 +157,6 @@ static int int3496_probe(struct platform_device *pdev)
return ret;
}
- /* queue initial processing of id-pin */
- queue_delayed_work(system_wq, &data->work, 0);
-
platform_set_drvdata(pdev, data);
return 0;
--
2.14.3
Apparently using the manual Maud/Naud mode does not work on KBL. The
details on the failure mode are scarce, except that there's no audio,
and there is obviously no idea on the root cause either. It is also
unknown whether the failure can be reproduced on newer platforms in some
scenarios.
The problem was introduced when switching from automatic mode to manual
mode in commit 6014ac122ed0 ("drm/i915/audio: set proper N/M in
modeset"). Instead of reverting that, disable the feature on KBL as a
workaround.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104093
Reported-by: Quanxian Wang <quanxian.wang(a)intel.com>
Fixes: 6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset")
Cc: <stable(a)vger.kernel.org> # v4.10+
Cc: Keqiao Zhang <keqiao.zhang(a)intel.com>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mengdong Lin <mengdong.lin(a)intel.com>
Cc: Libin Yang <libin.yang(a)linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: Quanxian Wang <quanxian.wang(a)intel.com>
Cc: Wang Zhijun <zhijunx.wang(a)intel.com>
Cc: Cui Yueping <yuepingx.cui(a)intel.com>
Cc: Alice Liu <alice.liu(a)intel.com>
Cc: intel-gfx(a)lists.freedesktop.org
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
---
UNTESTED. Please provide Tested-by's on the affected KBLs, but *also* on
CFL, CNL, etc.
---
drivers/gpu/drm/i915/intel_audio.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c
index 522d54fecb53..b7634cff12b6 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -294,12 +294,19 @@ hsw_dp_audio_config_update(struct intel_encoder *encoder,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
enum port port = encoder->port;
enum pipe pipe = crtc->pipe;
- const struct dp_aud_n_m *nm;
+ const struct dp_aud_n_m *nm = NULL;
int rate;
u32 tmp;
rate = acomp ? acomp->aud_sample_rate[port] : 0;
- nm = audio_config_dp_get_n_m(crtc_state, rate);
+
+ /*
+ * FIXME: For reasons still unknown, there seem to be issues with the
+ * manual Maud/Naud mode on KBL.
+ */
+ if (!IS_KABYLAKE(dev_priv))
+ nm = audio_config_dp_get_n_m(crtc_state, rate);
+
if (nm)
DRM_DEBUG_KMS("using Maud %u, Naud %u\n", nm->m, nm->n);
else
--
2.11.0
Hi,
not sure whether this is the best list to ask for that, but maybe
somebody from -stable interested people has hit similar problem..
if it's not appropriate list to ask/report, please let me know
since we started rolling to 4.14.x kernels, we've experienced multiple
KVM guest panics (with 4.14 on hosts)
We've first hit it with 4.14.12, yesterday I had similar problem with 4.14.16.
backtraces can be observed here:
http://nik.lbox.cz/download/guest-panic-host-4.14.12.pnghttp://nik.lbox.cz/download/guest-panic-host-4.14.16.png
sorry I don't have anything more complete
they are a bit different, but there are some similarities (ie double_fault)
also important to note, both are from different host systems.
after reverting hosts to 4.4, crashes are gone.
my question is, did anyone hit similar problem? Is this something
know, maybe fixed in 4.14.17? (I'll give 4.14.17 try anyways I suppose)
(or latest git?)
could it be related to page table isolation enabled hosts?
btw hosts are running x86_64 centos 7, guests are either centos 6
or centos 7
If I could provide any further info, let me know
BR
nik
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28.rijna 168, 709 00 Ostrava
tel.: +420 591 166 214
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis(a)linuxbox.cz
-------------------------------------
The patch titled
Subject: mm, swap, frontswap: fix THP swap if frontswap enabled
has been added to the -mm tree. Its filename is
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-frontswap-fix-thp-swap-if-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-swap-frontswap-fix-thp-swap-if-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Subject: mm, swap, frontswap: fix THP swap if frontswap enabled
It was reported by Sergey Senozhatsky that if THP (Transparent Huge Page)
and frontswap (via zswap) are both enabled, when memory goes low so that
swap is triggered, segfault and memory corruption will occur in random
user space applications as follow,
kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
#0 0x00007fc08889ae0d _int_malloc (libc.so.6)
#1 0x00007fc08889c2f3 malloc (libc.so.6)
#2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
#3 0x0000560e6005e75c n/a (urxvt)
#4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
#5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
#6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
#7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
#8 0x0000560e6005cb55 ev_run (urxvt)
#9 0x0000560e6003b9b9 main (urxvt)
#10 0x00007fc08883af4a __libc_start_main (libc.so.6)
#11 0x0000560e6003f9da _start (urxvt)
After bisection, it was found the first bad commit is bd4c82c22c367e068
("mm, THP, swap: delay splitting THP after swapped out").
The root cause is as follows:
When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages to
improve performance. But zswap (frontswap) will treat THP as a normal
page, so only the head page is saved. After swapping in, tail pages will
not be restored to their original contents, causing memory corruption in
the applications.
This is fixed by refusing to save page in the frontswap store functions if
the page is a THP. So that the THP will be swapped out to swap device.
Another choice is to split THP if frontswap is enabled. But it is found
that the frontswap enabling isn't flexible. For example, if
CONFIG_ZSWAP=y (cannot be module), frontswap will be enabled even if zswap
itself isn't enabled.
Frontswap has multiple backends, to make it easy for one backend to enable
THP support, the THP checking is put in backend frontswap store functions
instead of the general interfaces.
Link: http://lkml.kernel.org/r/20180209084947.22749-1-ying.huang@intel.com
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Suggested-by: Minchan Kim <minchan(a)kernel.org> [put THP checking in backend]
Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Dan Streetman <ddstreet(a)ieee.org>
Cc: Seth Jennings <sjenning(a)redhat.com>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Shaohua Li <shli(a)kernel.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: <stable(a)vger.kernel.org> [4.14]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/xen/tmem.c | 4 ++++
mm/zswap.c | 6 ++++++
2 files changed, 10 insertions(+)
diff -puN drivers/xen/tmem.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 drivers/xen/tmem.c
--- a/drivers/xen/tmem.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3
+++ a/drivers/xen/tmem.c
@@ -284,6 +284,10 @@ static int tmem_frontswap_store(unsigned
int pool = tmem_frontswap_poolid;
int ret;
+ /* THP isn't supported */
+ if (PageTransHuge(page))
+ return -1;
+
if (pool < 0)
return -1;
if (ind64 != ind)
diff -puN mm/zswap.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 mm/zswap.c
--- a/mm/zswap.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3
+++ a/mm/zswap.c
@@ -1007,6 +1007,12 @@ static int zswap_frontswap_store(unsigne
u8 *src, *dst;
struct zswap_header zhdr = { .swpentry = swp_entry(type, offset) };
+ /* THP isn't supported */
+ if (PageTransHuge(page)) {
+ ret = -EINVAL;
+ goto reject;
+ }
+
if (!zswap_enabled || !tree) {
ret = -ENODEV;
goto reject;
_
Patches currently in -mm which might be from huang.ying.caritas(a)gmail.com are
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3.patch
The patch titled
Subject: mm, swap, frontswap: Fix THP swap if frontswap enabled
has been removed from the -mm tree. Its filename was
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch
This patch was dropped because an updated version will be merged
------------------------------------------------------
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Subject: mm, swap, frontswap: Fix THP swap if frontswap enabled
It was reported by Sergey Senozhatsky that if THP (Transparent Huge Page)
and frontswap (via zswap) are both enabled, when memory goes low so that
swap is triggered, segfault and memory corruption will occur in random
user space applications as follow,
kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
#0 0x00007fc08889ae0d _int_malloc (libc.so.6)
#1 0x00007fc08889c2f3 malloc (libc.so.6)
#2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
#3 0x0000560e6005e75c n/a (urxvt)
#4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
#5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
#6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
#7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
#8 0x0000560e6005cb55 ev_run (urxvt)
#9 0x0000560e6003b9b9 main (urxvt)
#10 0x00007fc08883af4a __libc_start_main (libc.so.6)
#11 0x0000560e6003f9da _start (urxvt)
After bisection, it was found the first bad commit is bd4c82c22c367e068
("mm, THP, swap: delay splitting THP after swapped out").
The root cause is as follows:
When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages instead
to improve the performance. But zswap (frontswap) will treat THP as
normal page, so only the head page is saved. After swapping in, tail
pages will not be restored to its original contents, so cause the memory
corruption in the applications.
This is fixed via splitting THP before writing the page to swap device if
frontswap is enabled. To deal with the situation where frontswap is
enabled at runtime, whether the page is THP is checked before using
frontswap during swapping out too.
Link: http://lkml.kernel.org/r/20180207070035.30302-1-ying.huang@intel.com
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Dan Streetman <ddstreet(a)ieee.org>
Cc: Seth Jennings <sjenning(a)redhat.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Shaohua Li <shli(a)kernel.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.14+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_io.c | 2 +-
mm/swapfile.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff -puN mm/page_io.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled mm/page_io.c
--- a/mm/page_io.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled
+++ a/mm/page_io.c
@@ -250,7 +250,7 @@ int swap_writepage(struct page *page, st
unlock_page(page);
goto out;
}
- if (frontswap_store(page) == 0) {
+ if (!PageTransHuge(page) && frontswap_store(page) == 0) {
set_page_writeback(page);
unlock_page(page);
end_page_writeback(page);
diff -puN mm/swapfile.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled mm/swapfile.c
--- a/mm/swapfile.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled
+++ a/mm/swapfile.c
@@ -934,6 +934,9 @@ int get_swap_pages(int n_goal, bool clus
/* Only single cluster request supported */
WARN_ON_ONCE(n_goal > 1 && cluster);
+ /* Frontswap doesn't support THP */
+ if (frontswap_enabled() && cluster)
+ goto noswap;
avail_pgs = atomic_long_read(&nr_swap_pages) / nr_pages;
if (avail_pgs <= 0)
_
Patches currently in -mm which might be from huang.ying.caritas(a)gmail.com are
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3.patch
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Al Viro reported:
For substring - sure, but what about something like "*a*b" and "a*b"?
AFAICS, filter_parse_regex() ends up with identical results in both
cases - MATCH_GLOB and *search = "a*b". And no way for the caller
to tell one from another.
Testing this with the following:
# cd /sys/kernel/tracing
# echo '*raw*lock' > set_ftrace_filter
bash: echo: write error: Invalid argument
With this patch:
# echo '*raw*lock' > set_ftrace_filter
# cat set_ftrace_filter
_raw_read_trylock
_raw_write_trylock
_raw_read_unlock
_raw_spin_unlock
_raw_write_unlock
_raw_spin_trylock
_raw_spin_lock
_raw_write_lock
_raw_read_lock
Al recommended not setting the search buffer to skip the first '*' unless we
know we are not using MATCH_GLOB. This implements his suggested logic.
Link: http://lkml.kernel.org/r/20180127170748.GF13338@ZenIV.linux.org.uk
Cc: stable(a)vger.kernel.org
Fixes: 60f1d5e3bac44 ("ftrace: Support full glob matching")
Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Suggsted-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/trace/trace_events_filter.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
index 61e7f0678d33..a764aec3c9a1 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -400,7 +400,6 @@ enum regex_type filter_parse_regex(char *buff, int len, char **search, int *not)
for (i = 0; i < len; i++) {
if (buff[i] == '*') {
if (!i) {
- *search = buff + 1;
type = MATCH_END_ONLY;
} else if (i == len - 1) {
if (type == MATCH_END_ONLY)
@@ -410,14 +409,14 @@ enum regex_type filter_parse_regex(char *buff, int len, char **search, int *not)
buff[i] = 0;
break;
} else { /* pattern continues, use full glob */
- type = MATCH_GLOB;
- break;
+ return MATCH_GLOB;
}
} else if (strchr("[?\\", buff[i])) {
- type = MATCH_GLOB;
- break;
+ return MATCH_GLOB;
}
}
+ if (buff[0] == '*')
+ *search = buff + 1;
return type;
}
--
2.15.1
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
__unregister_ftrace_function_probe() will incorrectly parse the glob filter
because it resets the search variable that was setup by filter_parse_regex().
Al Viro reported this:
After that call of filter_parse_regex() we could have func_g.search not
equal to glob only if glob started with '!' or '*'. In the former case
we would've buggered off with -EINVAL (not = 1). In the latter we
would've set func_g.search equal to glob + 1, calculated the length of
that thing in func_g.len and proceeded to reset func_g.search back to
glob.
Suppose the glob is e.g. *foo*. We end up with
func_g.type = MATCH_MIDDLE_ONLY;
func_g.len = 3;
func_g.search = "*foo";
Feeding that to ftrace_match_record() will not do anything sane - we
will be looking for names containing "*foo" (->len is ignored for that
one).
Link: http://lkml.kernel.org/r/20180127031706.GE13338@ZenIV.linux.org.uk
Cc: stable(a)vger.kernel.org
Fixes: 3ba009297149f ("ftrace: Introduce ftrace_glob structure")
Reviewed-by: Dmitry Safonov <0x7f454c46(a)gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/trace/ftrace.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index dabd9d167d42..eac9ce2c57a2 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4456,7 +4456,6 @@ unregister_ftrace_function_probe_func(char *glob, struct trace_array *tr,
func_g.type = filter_parse_regex(glob, strlen(glob),
&func_g.search, ¬);
func_g.len = strlen(func_g.search);
- func_g.search = glob;
/* we do not support '!' for function probes */
if (WARN_ON(not))
--
2.15.1
From: Haozhong Zhang <haozhong.zhang(a)intel.com>
[ upstream commit 2a266f23550be997d783f27e704b9b40c4010292 Mon Sep 17 00:00:00 2001 ]
For example, when two APF's for page ready happen after one exit and
the first one becomes pending, the second one will result in #DF.
Instead, just handle the second page fault synchronously.
Reported-by: Ross Zwisler <zwisler(a)gmail.com>
Message-ID: <CAOxpaSUBf8QoOZQ1p4KfUp0jq76OKfGY4Uxs-Gg8ngReD99xww(a)mail.gmail.com>
Reported-by: Alec Blayne <ab(a)tevsa.net>
Signed-off-by: Haozhong Zhang <haozhong.zhang(a)intel.com>
Fixes: 664f8e26b00c7673a8303b0d40853a0c24ca93e1
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
arch/x86/kvm/mmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c4deb1f34faa..e577bacd4bd0 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3781,7 +3781,8 @@ static int kvm_arch_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, gfn_t gfn)
bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu)
{
if (unlikely(!lapic_in_kernel(vcpu) ||
- kvm_event_needs_reinjection(vcpu)))
+ kvm_event_needs_reinjection(vcpu) ||
+ vcpu->arch.exception.pending))
return false;
if (!vcpu->arch.apf.delivery_as_pf_vmexit && is_guest_mode(vcpu))
--
1.8.3.1
From: Eric Biggers <ebiggers(a)google.com>
The SHA-512 multibuffer code keeps track of the number of blocks pending
in each lane. The minimum of these values is used to identify the next
lane that will be completed. Unused lanes are set to a large number
(0xFFFFFFFF) so that they don't affect this calculation.
However, it was forgotten to set the lengths to this value in the
initial state, where all lanes are unused. As a result it was possible
for sha512_mb_mgr_get_comp_job_avx2() to select an unused lane, causing
a NULL pointer dereference. Specifically this could happen in the case
where ->update() was passed fewer than SHA512_BLOCK_SIZE bytes of data,
so it then called sha_complete_job() without having actually submitted
any blocks to the multi-buffer code. This hit a NULL pointer
dereference if another task happened to have submitted blocks
concurrently to the same CPU and the flush timer had not yet expired.
Fix this by initializing sha512_mb_mgr->lens correctly.
As usual, this bug was found by syzkaller.
Fixes: 45691e2d9b18 ("crypto: sha512-mb - submit/flush routines for AVX2")
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: <stable(a)vger.kernel.org> # v4.8+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c b/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c
index 36870b26067a..d08805032f01 100644
--- a/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c
+++ b/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c
@@ -57,10 +57,12 @@ void sha512_mb_mgr_init_avx2(struct sha512_mb_mgr *state)
{
unsigned int j;
- state->lens[0] = 0;
- state->lens[1] = 1;
- state->lens[2] = 2;
- state->lens[3] = 3;
+ /* initially all lanes are unused */
+ state->lens[0] = 0xFFFFFFFF00000000;
+ state->lens[1] = 0xFFFFFFFF00000001;
+ state->lens[2] = 0xFFFFFFFF00000002;
+ state->lens[3] = 0xFFFFFFFF00000003;
+
state->unused_lanes = 0xFF03020100;
for (j = 0; j < 4; j++)
state->ldata[j].job_in_lane = NULL;
--
2.16.0
From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
To allow dual pipelines utilising two WPF entities when available, the
VSP was updated to support header-mode display list in continuous
pipelines.
A small bug in the status check of the command register causes the
second pipeline to be directly afflicted by the running of the first;
appearing as a perceived performance issue with stuttering display.
Fix the vsp1_dl_list_hw_update_pending() call to ensure that the read
comparison corresponds to the correct pipeline.
Fixes: eaf4bfad6ad8 ("v4l: vsp1: Add support for header display
lists in continuous mode")
Cc: "Stable v4.14+" <stable(a)vger.kernel.org>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_dl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c
index 8cd03ee45f79..34b5ed2592f8 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -509,7 +509,8 @@ static bool vsp1_dl_list_hw_update_pending(struct vsp1_dl_manager *dlm)
return !!(vsp1_read(vsp1, VI6_DL_BODY_SIZE)
& VI6_DL_BODY_SIZE_UPD);
else
- return !!(vsp1_read(vsp1, VI6_CMD(dlm->index) & VI6_CMD_UPDHDR));
+ return !!(vsp1_read(vsp1, VI6_CMD(dlm->index))
+ & VI6_CMD_UPDHDR);
}
static bool vsp1_dl_hw_active(struct vsp1_dl_manager *dlm)
--
2.7.4
From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
To allow dual pipelines utilising two WPF entities when available, the
VSP was updated to support header-mode display list in continuous
pipelines.
A small bug in the status check of the command register causes the
second pipeline to be directly afflicted by the running of the first;
appearing as a perceived performance issue with stuttering display.
Fix the vsp1_dl_list_hw_update_pending() call to ensure that the read
comparison corresponds to the correct pipeline.
Fixes: eaf4bfad6ad8 ("v4l: vsp1: Add support for header display
lists in continuous mode")
Cc: "Stable v4.14+" <stable(a)vger.kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_dl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c
index 8cd03ee45f79..34b5ed2592f8 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -509,7 +509,8 @@ static bool vsp1_dl_list_hw_update_pending(struct vsp1_dl_manager *dlm)
return !!(vsp1_read(vsp1, VI6_DL_BODY_SIZE)
& VI6_DL_BODY_SIZE_UPD);
else
- return !!(vsp1_read(vsp1, VI6_CMD(dlm->index) & VI6_CMD_UPDHDR));
+ return !!(vsp1_read(vsp1, VI6_CMD(dlm->index))
+ & VI6_CMD_UPDHDR);
}
static bool vsp1_dl_hw_active(struct vsp1_dl_manager *dlm)
--
2.7.4
This is a note to let you know that I've just added the patch titled
scsi: storvsc: missing error code in storvsc_probe()
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:
scsi-storvsc-missing-error-code-in-storvsc_probe.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 ca8dc694045e9aa248e9916e0f614deb0494cb3d Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 16 Jan 2018 13:40:22 +0300
Subject: scsi: storvsc: missing error code in storvsc_probe()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit ca8dc694045e9aa248e9916e0f614deb0494cb3d upstream.
We should set the error code if fc_remote_port_add() fails.
Cc: <stable(a)vger.kernel.org> #v4.12+
Fixes: daf0cd445a21 ("scsi: storvsc: Add support for FC rport.")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Cathy Avery <cavery(a)redhat.com>
Acked-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Long Li <longli(a)microsoft.com>
---
drivers/scsi/storvsc_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1826,8 +1826,10 @@ static int storvsc_probe(struct hv_devic
fc_host_node_name(host) = stor_device->node_name;
fc_host_port_name(host) = stor_device->port_name;
stor_device->rport = fc_remote_port_add(host, 0, &ids);
- if (!stor_device->rport)
+ if (!stor_device->rport) {
+ ret = -ENOMEM;
goto err_out3;
+ }
}
#endif
return 0;
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.14/scsi-storvsc-missing-error-code-in-storvsc_probe.patch
On Tue, Feb 06, 2018 at 09:05:46PM +0000, Woodhouse, David wrote:
>
>
> On Tue, 2018-02-06 at 19:01 +0100, Paolo Bonzini wrote:
> > On 06/02/2018 18:29, David Woodhouse wrote:
> > > I've put together a linux-4.9.y branch at
> > > http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.9…
> > >
> > > Most of it is fairly straightforward, apart from the IBPB on context
> > > switch for which Tim has already posted a candidate. I wanted some more
> > > review on my backports of the KVM bits though, including some extra
> > > historical patches I pulled in.
> >
> > Looks good! Thanks for the work,
> >
> > Paolo
>
> Thanks. In that case, Greg, the full set is lined up in
> http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.9…
> or git://git.infradead.org/retpoline-stable linux-4.9.y
Many thanks for all of this work. I've now queued up all of these.
greg k-h
This is a note to let you know that I've just added the patch titled
KVM: nVMX: kmap() can't fail
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-nvmx-kmap-can-t-fail.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 42cf014d38d8822cce63703a467e00f65d000952 Mon Sep 17 00:00:00 2001
From: David Hildenbrand <david(a)redhat.com>
Date: Wed, 25 Jan 2017 11:58:57 +0100
Subject: KVM: nVMX: kmap() can't fail
From: David Hildenbrand <david(a)redhat.com>
commit 42cf014d38d8822cce63703a467e00f65d000952 upstream.
kmap() can't fail, therefore it will always return a valid pointer. Let's
just get rid of the unnecessary checks.
Signed-off-by: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 9 ---------
1 file changed, 9 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4756,10 +4756,6 @@ static int vmx_complete_nested_posted_in
return 0;
vapic_page = kmap(vmx->nested.virtual_apic_page);
- if (!vapic_page) {
- WARN_ON(1);
- return -ENOMEM;
- }
__kvm_apic_update_irr(vmx->nested.pi_desc->pir, vapic_page);
kunmap(vmx->nested.virtual_apic_page);
@@ -9584,11 +9580,6 @@ static inline bool nested_vmx_merge_msr_
if (!page)
return false;
msr_bitmap_l1 = (unsigned long *)kmap(page);
- if (!msr_bitmap_l1) {
- nested_release_page_clean(page);
- WARN_ON(1);
- return false;
- }
memset(msr_bitmap_l0, 0xff, PAGE_SIZE);
Patches currently in stable-queue which might be from david(a)redhat.com are
queue-4.9/kvm-nvmx-eliminate-vmcs02-pool.patch
queue-4.9/kvm-nvmx-vmx_complete_nested_posted_interrupt-can-t-fail.patch
queue-4.9/kvm-nvmx-kmap-can-t-fail.patch
mpls_label_ok() validates that the 'platform_label' array index from a
userspace netlink message payload is valid. Under speculation the
mpls_label_ok() result may not resolve in the CPU pipeline until after
the index is used to access an array element. Sanitize the index to zero
to prevent userspace-controlled arbitrary out-of-bounds speculation, a
precursor for a speculative execution side channel vulnerability.
Cc: <stable(a)vger.kernel.org>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: Eric W. Biederman <ebiederm(a)xmission.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
---
net/mpls/af_mpls.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 8ca9915befc8..aae3565c3a92 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -8,6 +8,7 @@
#include <linux/ipv6.h>
#include <linux/mpls.h>
#include <linux/netconf.h>
+#include <linux/nospec.h>
#include <linux/vmalloc.h>
#include <linux/percpu.h>
#include <net/ip.h>
@@ -935,24 +936,27 @@ static int mpls_nh_build_multi(struct mpls_route_config *cfg,
return err;
}
-static bool mpls_label_ok(struct net *net, unsigned int index,
+static bool mpls_label_ok(struct net *net, unsigned int *index,
struct netlink_ext_ack *extack)
{
+ bool is_ok = true;
+
/* Reserved labels may not be set */
- if (index < MPLS_LABEL_FIRST_UNRESERVED) {
+ if (*index < MPLS_LABEL_FIRST_UNRESERVED) {
NL_SET_ERR_MSG(extack,
"Invalid label - must be MPLS_LABEL_FIRST_UNRESERVED or higher");
- return false;
+ is_ok = false;
}
/* The full 20 bit range may not be supported. */
- if (index >= net->mpls.platform_labels) {
+ if (is_ok && *index >= net->mpls.platform_labels) {
NL_SET_ERR_MSG(extack,
"Label >= configured maximum in platform_labels");
- return false;
+ is_ok = false;
}
- return true;
+ *index = array_index_nospec(*index, net->mpls.platform_labels);
+ return is_ok;
}
static int mpls_route_add(struct mpls_route_config *cfg,
@@ -975,7 +979,7 @@ static int mpls_route_add(struct mpls_route_config *cfg,
index = find_free_label(net);
}
- if (!mpls_label_ok(net, index, extack))
+ if (!mpls_label_ok(net, &index, extack))
goto errout;
/* Append makes no sense with mpls */
@@ -1052,7 +1056,7 @@ static int mpls_route_del(struct mpls_route_config *cfg,
index = cfg->rc_label;
- if (!mpls_label_ok(net, index, extack))
+ if (!mpls_label_ok(net, &index, extack))
goto errout;
mpls_route_update(net, index, NULL, &cfg->rc_nlinfo);
@@ -1810,7 +1814,7 @@ static int rtm_to_route_config(struct sk_buff *skb,
goto errout;
if (!mpls_label_ok(cfg->rc_nlinfo.nl_net,
- cfg->rc_label, extack))
+ &cfg->rc_label, extack))
goto errout;
break;
}
@@ -2137,7 +2141,7 @@ static int mpls_getroute(struct sk_buff *in_skb, struct nlmsghdr *in_nlh,
goto errout;
}
- if (!mpls_label_ok(net, in_label, extack)) {
+ if (!mpls_label_ok(net, &in_label, extack)) {
err = -EINVAL;
goto errout;
}
On Thu, 08 Feb 2018 15:20:16 +0000
Eric Anholt <eric(a)anholt.net> wrote:
> Boris Brezillon <boris.brezillon(a)bootlin.com> writes:
>
> > All bcm2835 PLLs should be gated before their rate can be changed.
> > Setting CLK_SET_RATE_GATE will let the core enforce that, but this is
> > not enough to make the code work in all situations. Indeed, the
> > CLK_SET_RATE_GATE flag prevents a user from changing the rate while
> > the clock is enabled, but this check only guarantees there's no Linux
> > users. In our case, the clock might have been enabled by the
> > bootloader/FW, and, because we have CLK_IGNORE_UNUSED set, Linux never
> > disables the PLL. So we have to make sure the PLL is actually disabled
> > before changing the rate.
> >
> > Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
> > Cc: <stable(a)vger.kernel.org>
> > Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
> > ---
> > drivers/clk/bcm/clk-bcm2835.c | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> > index 6c5d4a8e426c..051ce769c109 100644
> > --- a/drivers/clk/bcm/clk-bcm2835.c
> > +++ b/drivers/clk/bcm/clk-bcm2835.c
> > @@ -678,6 +678,18 @@ static int bcm2835_pll_set_rate(struct clk_hw *hw,
> > u32 ana[4];
> > int i;
> >
> > + /*
> > + * Normally, the CLK_SET_RATE_GATE flag prevents a user from changing
> > + * the rate while the clock is enabled, but this check only makes sure
> > + * there's no Linux users.
> > + * In our case, the clock might have been enabled by the bootloader/FW,
> > + * and, since CLK_IGNORE_UNUSED flag is set, Linux never disables it.
> > + * So we have to make sure the clk is actually disabled before changing
> > + * the rate.
> > + */
> > + if (bcm2835_pll_is_on(hw))
> > + bcm2835_pll_off(hw);
> > +
>
> I'm not sure this improves the situation. If the PLL was on, then
> presumably there's a divider using it and a CM clock using that, so
> we'll probably end up driving some glitches on them.
Hm, yes, but if someone is trying to change the rate of the PLL, and the
core doesn't know other clks depend on this PLL (which is the case if
we reach this point), we're already in big trouble.
>
> Does the common clk framework have a way to disable unused clocks from
> the leaf clocks up to this root, before the general
> disable-unused-clocks path happens late in the boot process?
Not that I know of. What do you have in mind?
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
On Thu, 08 Feb 2018 15:15:42 +0000
Eric Anholt <eric(a)anholt.net> wrote:
> Boris Brezillon <boris.brezillon(a)bootlin.com> writes:
>
> > In order to enable a PLL, not only the PLL has to be powered up and
> > locked, but you also have to de-assert the reset signal. The last part
> > was missing. Add it so PLLs that were not enabled by the FW/bootloader
> > can be enabled from Linux.
> >
> > Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
> > Cc: <stable(a)vger.kernel.org>
> > Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
> > ---
> > drivers/clk/bcm/clk-bcm2835.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> > index a07f6451694a..6c5d4a8e426c 100644
> > --- a/drivers/clk/bcm/clk-bcm2835.c
> > +++ b/drivers/clk/bcm/clk-bcm2835.c
> > @@ -602,6 +602,9 @@ static void bcm2835_pll_off(struct clk_hw *hw)
> > const struct bcm2835_pll_data *data = pll->data;
> >
> > spin_lock(&cprman->regs_lock);
> > + cprman_write(cprman, data->a2w_ctrl_reg,
> > + cprman_read(cprman, data->a2w_ctrl_reg) &
> > + ~A2W_PLL_CTRL_PRST_DISABLE);
> > cprman_write(cprman, data->cm_ctrl_reg,
> > cprman_read(cprman, data->cm_ctrl_reg) |
> > CM_PLL_ANARST);
>
> For turning off, the FW just does the equivalent of:
>
> cprman_write(cprman, data->cm_ctrl_reg, CM_PLL_ANARST);
> cprman_write(cprman, data->a2w_ctrl_reg, A2W_PLL_CTRL_PWRDN);
>
> How about we do that, instead?
Agreed.
>
> > @@ -640,6 +643,10 @@ static int bcm2835_pll_on(struct clk_hw *hw)
> > cpu_relax();
> > }
> >
> > + cprman_write(cprman, data->a2w_ctrl_reg,
> > + cprman_read(cprman, data->a2w_ctrl_reg) |
> > + A2W_PLL_CTRL_PRST_DISABLE);
> > +
> > return 0;
> > }
>
> I agree with this hunk -- they drop PRST at the very end, after lock.
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
From: Borislav Petkov <bp(a)suse.de>
commit a15a753539eca8ba243d576f02e7ca9c4b7d7042 upstream with minor
adjustments.
Doing so is completely void of sense for multiple reasons so prevent
it. Set dis_ucode_ldr to true and thus disable the microcode loader by
default to address xen pv guests which execute the AP path but not the
BSP path.
By having it turned off by default, the APs won't run into the loader
either.
Also, check CPUID(1).ECX[31] which hypervisors set. Well almost, not the
xen pv one. That one gets the aforementioned "fix".
Also, improve the detection method by caching the final decision whether
to continue loading in dis_ucode_ldr and do it once on the BSP. The APs
then simply test that value.
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Tested-by: Juergen Gross <jgross(a)suse.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Acked-by: Juergen Gross <jgross(a)suse.com>
Link: http://lkml.kernel.org/r/20161218164414.9649-4-bp@alien8.de
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org> # 4.4.x
Signed-off-by: Rolf Neugebauer <rolf.neugebauer(a)docker.com>
---
arch/x86/kernel/cpu/microcode/core.c | 28 +++++++++++++++++++---------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index b3e94ef461fd..1b3e0aa4c511 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -44,7 +44,7 @@
static struct microcode_ops *microcode_ops;
-static bool dis_ucode_ldr;
+static bool dis_ucode_ldr = true;
static int __init disable_loader(char *str)
{
@@ -81,6 +81,7 @@ struct cpu_info_ctx {
static bool __init check_loader_disabled_bsp(void)
{
+ u32 a, b, c, d;
#ifdef CONFIG_X86_32
const char *cmdline = (const char *)__pa_nodebug(boot_command_line);
const char *opt = "dis_ucode_ldr";
@@ -93,8 +94,23 @@ static bool __init check_loader_disabled_bsp(void)
bool *res = &dis_ucode_ldr;
#endif
- if (cmdline_find_option_bool(cmdline, option))
- *res = true;
+ if (!have_cpuid_p())
+ return *res;
+
+ a = 1;
+ c = 0;
+ native_cpuid(&a, &b, &c, &d);
+
+ /*
+ * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
+ * completely accurate as xen pv guests don't see that CPUID bit set but
+ * that's good enough as they don't land on the BSP path anyway.
+ */
+ if (c & BIT(31))
+ return *res;
+
+ if (cmdline_find_option_bool(cmdline, option) <= 0)
+ *res = false;
return *res;
}
@@ -126,9 +142,6 @@ void __init load_ucode_bsp(void)
if (check_loader_disabled_bsp())
return;
- if (!have_cpuid_p())
- return;
-
vendor = x86_vendor();
family = x86_family();
@@ -162,9 +175,6 @@ void load_ucode_ap(void)
if (check_loader_disabled_ap())
return;
- if (!have_cpuid_p())
- return;
-
vendor = x86_vendor();
family = x86_family();
--
2.16.0
This is a note to let you know that I've just added the patch titled
x86/microcode: Do the family check first
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-microcode-do-the-family-check-first.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 1f161f67a272cc4f29f27934dd3f74cb657eb5c4 Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp(a)suse.de>
Date: Thu, 12 Oct 2017 13:23:16 +0200
Subject: x86/microcode: Do the family check first
From: Borislav Petkov <bp(a)suse.de>
commit 1f161f67a272cc4f29f27934dd3f74cb657eb5c4 upstream with adjustments.
On CPUs like AMD's Geode, for example, we shouldn't even try to load
microcode because they do not support the modern microcode loading
interface.
However, we do the family check *after* the other checks whether the
loader has been disabled on the command line or whether we're running in
a guest.
So move the family checks first in order to exit early if we're being
loaded on an unsupported family.
Reported-and-tested-by: Sven Glodowski <glodi1(a)arcor.de>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Cc: <stable(a)vger.kernel.org> # 4.11..
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://bugzilla.suse.com/show_bug.cgi?id=1061396
Link: http://lkml.kernel.org/r/20171012112316.977-1-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Rolf Neugebauer <rolf.neugebauer(a)docker.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/microcode/core.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -86,9 +86,6 @@ static bool __init check_loader_disabled
bool *res = &dis_ucode_ldr;
#endif
- if (!have_cpuid_p())
- return *res;
-
a = 1;
c = 0;
native_cpuid(&a, &b, &c, &d);
@@ -130,8 +127,9 @@ void __init load_ucode_bsp(void)
{
int vendor;
unsigned int family;
+ bool intel = true;
- if (check_loader_disabled_bsp())
+ if (!have_cpuid_p())
return;
vendor = x86_cpuid_vendor();
@@ -139,16 +137,27 @@ void __init load_ucode_bsp(void)
switch (vendor) {
case X86_VENDOR_INTEL:
- if (family >= 6)
- load_ucode_intel_bsp();
+ if (family < 6)
+ return;
break;
+
case X86_VENDOR_AMD:
- if (family >= 0x10)
- load_ucode_amd_bsp(family);
+ if (family < 0x10)
+ return;
+ intel = false;
break;
+
default:
- break;
+ return;
}
+
+ if (check_loader_disabled_bsp())
+ return;
+
+ if (intel)
+ load_ucode_intel_bsp();
+ else
+ load_ucode_amd_bsp(family);
}
static bool check_loader_disabled_ap(void)
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-retpoline-simplify-vmexit_fill_rsb.patch
queue-4.9/x86-cpufeatures-clean-up-spectre-v2-related-cpuid-flags.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch
queue-4.9/x86-nospec-fix-header-guards-names.patch
queue-4.9/x86-alternative-print-unadorned-pointers.patch
queue-4.9/x86-microcode-do-the-family-check-first.patch
queue-4.9/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.9/x86-pti-mark-constant-arrays-as-__initconst.patch
queue-4.9/x86-bugs-drop-one-mitigation-from-dmesg.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
This is a note to let you know that I've just added the patch titled
x86/microcode: Do the family check first
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-microcode-do-the-family-check-first.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 1f161f67a272cc4f29f27934dd3f74cb657eb5c4 Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp(a)suse.de>
Date: Thu, 12 Oct 2017 13:23:16 +0200
Subject: x86/microcode: Do the family check first
From: Borislav Petkov <bp(a)suse.de>
commit 1f161f67a272cc4f29f27934dd3f74cb657eb5c4 upstream with adjustments.
On CPUs like AMD's Geode, for example, we shouldn't even try to load
microcode because they do not support the modern microcode loading
interface.
However, we do the family check *after* the other checks whether the
loader has been disabled on the command line or whether we're running in
a guest.
So move the family checks first in order to exit early if we're being
loaded on an unsupported family.
Reported-and-tested-by: Sven Glodowski <glodi1(a)arcor.de>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Cc: <stable(a)vger.kernel.org> # 4.11..
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://bugzilla.suse.com/show_bug.cgi?id=1061396
Link: http://lkml.kernel.org/r/20171012112316.977-1-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Rolf Neugebauer <rolf.neugebauer(a)docker.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/microcode/core.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -94,9 +94,6 @@ static bool __init check_loader_disabled
bool *res = &dis_ucode_ldr;
#endif
- if (!have_cpuid_p())
- return *res;
-
a = 1;
c = 0;
native_cpuid(&a, &b, &c, &d);
@@ -138,8 +135,9 @@ void __init load_ucode_bsp(void)
{
int vendor;
unsigned int family;
+ bool intel = true;
- if (check_loader_disabled_bsp())
+ if (!have_cpuid_p())
return;
vendor = x86_vendor();
@@ -147,16 +145,27 @@ void __init load_ucode_bsp(void)
switch (vendor) {
case X86_VENDOR_INTEL:
- if (family >= 6)
- load_ucode_intel_bsp();
+ if (family < 6)
+ return;
break;
+
case X86_VENDOR_AMD:
- if (family >= 0x10)
- load_ucode_amd_bsp(family);
+ if (family < 0x10)
+ return;
+ intel = false;
break;
+
default:
- break;
+ return;
}
+
+ if (check_loader_disabled_bsp())
+ return;
+
+ if (intel)
+ load_ucode_intel_bsp();
+ else
+ load_ucode_amd_bsp(family);
}
static bool check_loader_disabled_ap(void)
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.4/x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch
queue-4.4/x86-microcode-do-the-family-check-first.patch
This is a note to let you know that I've just added the patch titled
x86/microcode/AMD: Do not load when running on a hypervisor
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.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 a15a753539eca8ba243d576f02e7ca9c4b7d7042 Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp(a)suse.de>
Date: Sun, 18 Dec 2016 17:44:13 +0100
Subject: x86/microcode/AMD: Do not load when running on a hypervisor
From: Borislav Petkov <bp(a)suse.de>
commit a15a753539eca8ba243d576f02e7ca9c4b7d7042 upstream with minor
adjustments.
Doing so is completely void of sense for multiple reasons so prevent
it. Set dis_ucode_ldr to true and thus disable the microcode loader by
default to address xen pv guests which execute the AP path but not the
BSP path.
By having it turned off by default, the APs won't run into the loader
either.
Also, check CPUID(1).ECX[31] which hypervisors set. Well almost, not the
xen pv one. That one gets the aforementioned "fix".
Also, improve the detection method by caching the final decision whether
to continue loading in dis_ucode_ldr and do it once on the BSP. The APs
then simply test that value.
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Tested-by: Juergen Gross <jgross(a)suse.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Acked-by: Juergen Gross <jgross(a)suse.com>
Link: http://lkml.kernel.org/r/20161218164414.9649-4-bp@alien8.de
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Rolf Neugebauer <rolf.neugebauer(a)docker.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/microcode/core.c | 28 +++++++++++++++++++---------
1 file changed, 19 insertions(+), 9 deletions(-)
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -44,7 +44,7 @@
static struct microcode_ops *microcode_ops;
-static bool dis_ucode_ldr;
+static bool dis_ucode_ldr = true;
static int __init disable_loader(char *str)
{
@@ -81,6 +81,7 @@ struct cpu_info_ctx {
static bool __init check_loader_disabled_bsp(void)
{
+ u32 a, b, c, d;
#ifdef CONFIG_X86_32
const char *cmdline = (const char *)__pa_nodebug(boot_command_line);
const char *opt = "dis_ucode_ldr";
@@ -93,8 +94,23 @@ static bool __init check_loader_disabled
bool *res = &dis_ucode_ldr;
#endif
- if (cmdline_find_option_bool(cmdline, option))
- *res = true;
+ if (!have_cpuid_p())
+ return *res;
+
+ a = 1;
+ c = 0;
+ native_cpuid(&a, &b, &c, &d);
+
+ /*
+ * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
+ * completely accurate as xen pv guests don't see that CPUID bit set but
+ * that's good enough as they don't land on the BSP path anyway.
+ */
+ if (c & BIT(31))
+ return *res;
+
+ if (cmdline_find_option_bool(cmdline, option) <= 0)
+ *res = false;
return *res;
}
@@ -126,9 +142,6 @@ void __init load_ucode_bsp(void)
if (check_loader_disabled_bsp())
return;
- if (!have_cpuid_p())
- return;
-
vendor = x86_vendor();
family = x86_family();
@@ -162,9 +175,6 @@ void load_ucode_ap(void)
if (check_loader_disabled_ap())
return;
- if (!have_cpuid_p())
- return;
-
vendor = x86_vendor();
family = x86_family();
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.4/x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch
queue-4.4/x86-microcode-do-the-family-check-first.patch
This is a note to let you know that I've just added the patch titled
drm: rcar-du: Use the VBK interrupt for vblank events
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-rcar-du-use-the-vbk-interrupt-for-vblank-events.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 cbbb90b0c084d7dfb2ed8e3fecf8df200fbdd2a0 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Date: Mon, 10 Jul 2017 23:46:39 +0300
Subject: drm: rcar-du: Use the VBK interrupt for vblank events
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
commit cbbb90b0c084d7dfb2ed8e3fecf8df200fbdd2a0 upstream.
When implementing support for interlaced modes, the driver switched from
reporting vblank events on the vertical blanking (VBK) interrupt to the
frame end interrupt (FRM). This incorrectly divided the reported refresh
rate by two. Fix it by moving back to the VBK interrupt.
Fixes: 906eff7fcada ("drm: rcar-du: Implement support for interlaced modes")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
Signed-off-by: thongsyho <thong.ho.px(a)rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -551,7 +551,7 @@ static irqreturn_t rcar_du_crtc_irq(int
status = rcar_du_crtc_read(rcrtc, DSSR);
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
- if (status & DSSR_FRM) {
+ if (status & DSSR_VBK) {
drm_crtc_handle_vblank(&rcrtc->crtc);
rcar_du_crtc_finish_page_flip(rcrtc);
ret = IRQ_HANDLED;
Patches currently in stable-queue which might be from laurent.pinchart+renesas(a)ideasonboard.com are
queue-4.9/drm-rcar-du-use-the-vbk-interrupt-for-vblank-events.patch
queue-4.9/drm-rcar-du-fix-race-condition-when-disabling-planes-at-crtc-stop.patch
This is a note to let you know that I've just added the patch titled
drm: rcar-du: Fix race condition when disabling planes at CRTC stop
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-rcar-du-fix-race-condition-when-disabling-planes-at-crtc-stop.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 641307df71fe77d7b38a477067495ede05d47295 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Date: Sat, 29 Jul 2017 02:31:33 +0300
Subject: drm: rcar-du: Fix race condition when disabling planes at CRTC stop
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
commit 641307df71fe77d7b38a477067495ede05d47295 upstream.
When stopping the CRTC the driver must disable all planes and wait for
the change to take effect at the next vblank. Merely calling
drm_crtc_wait_one_vblank() is not enough, as the function doesn't
include any mechanism to handle the race with vblank interrupts.
Replace the drm_crtc_wait_one_vblank() call with a manual mechanism that
handles the vblank interrupt race.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
Signed-off-by: thongsyho <thong.ho.px(a)rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 53 +++++++++++++++++++++++++++++----
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 8 ++++
2 files changed, 55 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -392,6 +392,31 @@ static void rcar_du_crtc_start(struct rc
rcrtc->started = true;
}
+static void rcar_du_crtc_disable_planes(struct rcar_du_crtc *rcrtc)
+{
+ struct rcar_du_device *rcdu = rcrtc->group->dev;
+ struct drm_crtc *crtc = &rcrtc->crtc;
+ u32 status;
+ /* Make sure vblank interrupts are enabled. */
+ drm_crtc_vblank_get(crtc);
+ /*
+ * Disable planes and calculate how many vertical blanking interrupts we
+ * have to wait for. If a vertical blanking interrupt has been triggered
+ * but not processed yet, we don't know whether it occurred before or
+ * after the planes got disabled. We thus have to wait for two vblank
+ * interrupts in that case.
+ */
+ spin_lock_irq(&rcrtc->vblank_lock);
+ rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
+ status = rcar_du_crtc_read(rcrtc, DSSR);
+ rcrtc->vblank_count = status & DSSR_VBK ? 2 : 1;
+ spin_unlock_irq(&rcrtc->vblank_lock);
+ if (!wait_event_timeout(rcrtc->vblank_wait, rcrtc->vblank_count == 0,
+ msecs_to_jiffies(100)))
+ dev_warn(rcdu->dev, "vertical blanking timeout\n");
+ drm_crtc_vblank_put(crtc);
+}
+
static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
{
struct drm_crtc *crtc = &rcrtc->crtc;
@@ -400,17 +425,16 @@ static void rcar_du_crtc_stop(struct rca
return;
/* Disable all planes and wait for the change to take effect. This is
- * required as the DSnPR registers are updated on vblank, and no vblank
- * will occur once the CRTC is stopped. Disabling planes when starting
- * the CRTC thus wouldn't be enough as it would start scanning out
- * immediately from old frame buffers until the next vblank.
+ * required as the plane enable registers are updated on vblank, and no
+ * vblank will occur once the CRTC is stopped. Disabling planes when
+ * starting the CRTC thus wouldn't be enough as it would start scanning
+ * out immediately from old frame buffers until the next vblank.
*
* This increases the CRTC stop delay, especially when multiple CRTCs
* are stopped in one operation as we now wait for one vblank per CRTC.
* Whether this can be improved needs to be researched.
*/
- rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
- drm_crtc_wait_one_vblank(crtc);
+ rcar_du_crtc_disable_planes(rcrtc);
/* Disable vertical blanking interrupt reporting. We first need to wait
* for page flip completion before stopping the CRTC as userspace
@@ -548,10 +572,25 @@ static irqreturn_t rcar_du_crtc_irq(int
irqreturn_t ret = IRQ_NONE;
u32 status;
+ spin_lock(&rcrtc->vblank_lock);
+
status = rcar_du_crtc_read(rcrtc, DSSR);
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
if (status & DSSR_VBK) {
+ /*
+ * Wake up the vblank wait if the counter reaches 0. This must
+ * be protected by the vblank_lock to avoid races in
+ * rcar_du_crtc_disable_planes().
+ */
+ if (rcrtc->vblank_count) {
+ if (--rcrtc->vblank_count == 0)
+ wake_up(&rcrtc->vblank_wait);
+ }
+ }
+ spin_unlock(&rcrtc->vblank_lock);
+
+ if (status & DSSR_VBK) {
drm_crtc_handle_vblank(&rcrtc->crtc);
rcar_du_crtc_finish_page_flip(rcrtc);
ret = IRQ_HANDLED;
@@ -606,6 +645,8 @@ int rcar_du_crtc_create(struct rcar_du_g
}
init_waitqueue_head(&rcrtc->flip_wait);
+ init_waitqueue_head(&rcrtc->vblank_wait);
+ spin_lock_init(&rcrtc->vblank_lock);
rcrtc->group = rgrp;
rcrtc->mmio_offset = mmio_offsets[index];
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -15,6 +15,7 @@
#define __RCAR_DU_CRTC_H__
#include <linux/mutex.h>
+#include <linux/spinlock.h>
#include <linux/wait.h>
#include <drm/drmP.h>
@@ -33,6 +34,9 @@ struct rcar_du_vsp;
* @started: whether the CRTC has been started and is running
* @event: event to post when the pending page flip completes
* @flip_wait: wait queue used to signal page flip completion
+ * @vblank_lock: protects vblank_wait and vblank_count
+ * @vblank_wait: wait queue used to signal vertical blanking
+ * @vblank_count: number of vertical blanking interrupts to wait for
* @outputs: bitmask of the outputs (enum rcar_du_output) driven by this CRTC
* @group: CRTC group this CRTC belongs to
*/
@@ -48,6 +52,10 @@ struct rcar_du_crtc {
struct drm_pending_vblank_event *event;
wait_queue_head_t flip_wait;
+ spinlock_t vblank_lock;
+ wait_queue_head_t vblank_wait;
+ unsigned int vblank_count;
+
unsigned int outputs;
struct rcar_du_group *group;
Patches currently in stable-queue which might be from laurent.pinchart+renesas(a)ideasonboard.com are
queue-4.9/drm-rcar-du-use-the-vbk-interrupt-for-vblank-events.patch
queue-4.9/drm-rcar-du-fix-race-condition-when-disabling-planes-at-crtc-stop.patch
This is a note to let you know that I've just added the patch titled
crypto: tcrypt - fix S/G table for test_aead_speed()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-tcrypt-fix-s-g-table-for-test_aead_speed.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1 Mon Sep 17 00:00:00 2001
From: Robert Baronescu <robert.baronescu(a)nxp.com>
Date: Tue, 10 Oct 2017 13:21:59 +0300
Subject: crypto: tcrypt - fix S/G table for test_aead_speed()
From: Robert Baronescu <robert.baronescu(a)nxp.com>
commit 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1 upstream.
In case buffer length is a multiple of PAGE_SIZE,
the S/G table is incorrectly generated.
Fix this by handling buflen = k * PAGE_SIZE separately.
Signed-off-by: Robert Baronescu <robert.baronescu(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Horia Geantă <horia.geanta(a)nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/tcrypt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -223,11 +223,13 @@ static void sg_init_aead(struct scatterl
}
sg_init_table(sg, np + 1);
- np--;
+ if (rem)
+ np--;
for (k = 0; k < np; k++)
sg_set_buf(&sg[k + 1], xbuf[k], PAGE_SIZE);
- sg_set_buf(&sg[k + 1], xbuf[k], rem);
+ if (rem)
+ sg_set_buf(&sg[k + 1], xbuf[k], rem);
}
static void test_aead_speed(const char *algo, int enc, unsigned int secs,
Patches currently in stable-queue which might be from robert.baronescu(a)nxp.com are
queue-4.9/crypto-tcrypt-fix-s-g-table-for-test_aead_speed.patch
This is a note to let you know that I've just added the patch titled
ASoC: simple-card: Fix misleading error message
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-simple-card-fix-misleading-error-message.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 7ac45d1635a4cd2e99a4b11903d4a2815ca1b27b Mon Sep 17 00:00:00 2001
From: Julian Scheel <julian(a)jusst.de>
Date: Wed, 24 May 2017 12:28:23 +0200
Subject: ASoC: simple-card: Fix misleading error message
From: Julian Scheel <julian(a)jusst.de>
commit 7ac45d1635a4cd2e99a4b11903d4a2815ca1b27b upstream.
In case cpu could not be found the error message would always refer to
/codec/ not being found in DT. Fix this by catching the cpu node not found
case explicitly.
Signed-off-by: Julian Scheel <julian(a)jusst.de>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: thongsyho <thong.ho.px(a)rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/generic/simple-card.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -232,13 +232,19 @@ static int asoc_simple_card_dai_link_of(
snprintf(prop, sizeof(prop), "%scpu", prefix);
cpu = of_get_child_by_name(node, prop);
+ if (!cpu) {
+ ret = -EINVAL;
+ dev_err(dev, "%s: Can't find %s DT node\n", __func__, prop);
+ goto dai_link_of_err;
+ }
+
snprintf(prop, sizeof(prop), "%splat", prefix);
plat = of_get_child_by_name(node, prop);
snprintf(prop, sizeof(prop), "%scodec", prefix);
codec = of_get_child_by_name(node, prop);
- if (!cpu || !codec) {
+ if (!codec) {
ret = -EINVAL;
dev_err(dev, "%s: Can't find %s DT node\n", __func__, prop);
goto dai_link_of_err;
Patches currently in stable-queue which might be from julian(a)jusst.de are
queue-4.9/asoc-simple-card-fix-misleading-error-message.patch
This is a note to let you know that I've just added the patch titled
ASoC: rsnd: don't call free_irq() on Parent SSI
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-rsnd-don-t-call-free_irq-on-parent-ssi.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 1f8754d4daea5f257370a52a30fcb22798c54516 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Tue, 16 May 2017 01:48:24 +0000
Subject: ASoC: rsnd: don't call free_irq() on Parent SSI
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
commit 1f8754d4daea5f257370a52a30fcb22798c54516 upstream.
If SSI uses shared pin, some SSI will be used as parent SSI.
Then, normal SSI's remove and Parent SSI's remove
(these are same SSI) will be called when unbind or remove timing.
In this case, free_irq() will be called twice.
This patch solve this issue.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Reported-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: thongsyho <thong.ho.px(a)rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sh/rcar/ssi.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -699,9 +699,14 @@ static int rsnd_ssi_dma_remove(struct rs
struct rsnd_priv *priv)
{
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
+ struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
struct device *dev = rsnd_priv_to_dev(priv);
int irq = ssi->irq;
+ /* Do nothing for SSI parent mod */
+ if (ssi_parent_mod == mod)
+ return 0;
+
/* PIO will request IRQ again */
devm_free_irq(dev, irq, mod);
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.9/asoc-rsnd-don-t-call-free_irq-on-parent-ssi.patch
queue-4.9/asoc-rsnd-avoid-duplicate-free_irq.patch
This is a note to let you know that I've just added the patch titled
ASoC: rsnd: avoid duplicate free_irq()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-rsnd-avoid-duplicate-free_irq.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e0936c3471a8411a5df327641fa3ffe12a2fb07b Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Wed, 9 Aug 2017 02:16:20 +0000
Subject: ASoC: rsnd: avoid duplicate free_irq()
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
commit e0936c3471a8411a5df327641fa3ffe12a2fb07b upstream.
commit 1f8754d4daea5f ("ASoC: rsnd: don't call free_irq() on
Parent SSI") fixed Parent SSI duplicate free_irq().
But on Renesas Sound, not only Parent SSI but also Multi SSI
have same issue.
This patch avoid duplicate free_irq() if it was not pure SSI.
Fixes: 1f8754d4daea5f ("ASoC: rsnd: don't call free_irq() on Parent SSI")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: thongsyho <thong.ho.px(a)rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sh/rcar/ssi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -699,12 +699,12 @@ static int rsnd_ssi_dma_remove(struct rs
struct rsnd_priv *priv)
{
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
- struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
+ struct rsnd_mod *pure_ssi_mod = rsnd_io_to_mod_ssi(io);
struct device *dev = rsnd_priv_to_dev(priv);
int irq = ssi->irq;
- /* Do nothing for SSI parent mod */
- if (ssi_parent_mod == mod)
+ /* Do nothing if non SSI (= SSI parent, multi SSI) mod */
+ if (pure_ssi_mod != mod)
return 0;
/* PIO will request IRQ again */
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.9/asoc-rsnd-don-t-call-free_irq-on-parent-ssi.patch
queue-4.9/asoc-rsnd-avoid-duplicate-free_irq.patch
This is a note to let you know that I've just added the patch titled
crypto: tcrypt - fix S/G table for test_aead_speed()
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:
crypto-tcrypt-fix-s-g-table-for-test_aead_speed.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 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1 Mon Sep 17 00:00:00 2001
From: Robert Baronescu <robert.baronescu(a)nxp.com>
Date: Tue, 10 Oct 2017 13:21:59 +0300
Subject: crypto: tcrypt - fix S/G table for test_aead_speed()
From: Robert Baronescu <robert.baronescu(a)nxp.com>
commit 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1 upstream.
In case buffer length is a multiple of PAGE_SIZE,
the S/G table is incorrectly generated.
Fix this by handling buflen = k * PAGE_SIZE separately.
Signed-off-by: Robert Baronescu <robert.baronescu(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Horia Geantă <horia.geanta(a)nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/tcrypt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -291,11 +291,13 @@ static void sg_init_aead(struct scatterl
}
sg_init_table(sg, np + 1);
- np--;
+ if (rem)
+ np--;
for (k = 0; k < np; k++)
sg_set_buf(&sg[k + 1], xbuf[k], PAGE_SIZE);
- sg_set_buf(&sg[k + 1], xbuf[k], rem);
+ if (rem)
+ sg_set_buf(&sg[k + 1], xbuf[k], rem);
}
static void test_aead_speed(const char *algo, int enc, unsigned int secs,
Patches currently in stable-queue which might be from robert.baronescu(a)nxp.com are
queue-4.4/crypto-tcrypt-fix-s-g-table-for-test_aead_speed.patch
This is a note to let you know that I've just added the patch titled
crypto: tcrypt - fix S/G table for test_aead_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:
crypto-tcrypt-fix-s-g-table-for-test_aead_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 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1 Mon Sep 17 00:00:00 2001
From: Robert Baronescu <robert.baronescu(a)nxp.com>
Date: Tue, 10 Oct 2017 13:21:59 +0300
Subject: crypto: tcrypt - fix S/G table for test_aead_speed()
From: Robert Baronescu <robert.baronescu(a)nxp.com>
commit 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1 upstream.
In case buffer length is a multiple of PAGE_SIZE,
the S/G table is incorrectly generated.
Fix this by handling buflen = k * PAGE_SIZE separately.
Signed-off-by: Robert Baronescu <robert.baronescu(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Horia Geantă <horia.geanta(a)nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/tcrypt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -198,11 +198,13 @@ static void sg_init_aead(struct scatterl
}
sg_init_table(sg, np + 1);
- np--;
+ if (rem)
+ np--;
for (k = 0; k < np; k++)
sg_set_buf(&sg[k + 1], xbuf[k], PAGE_SIZE);
- sg_set_buf(&sg[k + 1], xbuf[k], rem);
+ if (rem)
+ sg_set_buf(&sg[k + 1], xbuf[k], rem);
}
static void test_aead_speed(const char *algo, int enc, unsigned int secs,
Patches currently in stable-queue which might be from robert.baronescu(a)nxp.com are
queue-4.15/crypto-tcrypt-fix-s-g-table-for-test_aead_speed.patch
This is a note to let you know that I've just added the patch titled
kernel/exit.c: export abort() to modules
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:
kernel-exit.c-export-abort-to-modules.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 dc8635b78cd8669c37e230058d18c33af7451ab1 Mon Sep 17 00:00:00 2001
From: Andrew Morton <akpm(a)linux-foundation.org>
Date: Thu, 4 Jan 2018 16:17:56 -0800
Subject: kernel/exit.c: export abort() to modules
From: Andrew Morton <akpm(a)linux-foundation.org>
commit dc8635b78cd8669c37e230058d18c33af7451ab1 upstream.
gcc -fisolate-erroneous-paths-dereference can generate calls to abort()
from modular code too.
[arnd(a)arndb.de: drop duplicate exports of abort()]
Link: http://lkml.kernel.org/r/20180102103311.706364-1-arnd@arndb.de
Reported-by: Vineet Gupta <Vineet.Gupta1(a)synopsys.com>
Cc: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Alexey Brodkin <Alexey.Brodkin(a)synopsys.com>
Cc: Russell King <rmk+kernel(a)armlinux.org.uk>
Cc: Jose Abreu <Jose.Abreu(a)synopsys.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Evgeniy Didin <Evgeniy.Didin(a)synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/kernel/traps.c | 1 -
arch/m32r/kernel/traps.c | 1 -
arch/unicore32/kernel/traps.c | 1 -
kernel/exit.c | 1 +
4 files changed, 1 insertion(+), 3 deletions(-)
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -790,7 +790,6 @@ void abort(void)
/* if that doesn't kill us, halt */
panic("Oops failed to kill thread");
}
-EXPORT_SYMBOL(abort);
void __init trap_init(void)
{
--- a/arch/m32r/kernel/traps.c
+++ b/arch/m32r/kernel/traps.c
@@ -122,7 +122,6 @@ void abort(void)
/* if that doesn't kill us, halt */
panic("Oops failed to kill thread");
}
-EXPORT_SYMBOL(abort);
void __init trap_init(void)
{
--- a/arch/unicore32/kernel/traps.c
+++ b/arch/unicore32/kernel/traps.c
@@ -298,7 +298,6 @@ void abort(void)
/* if that doesn't kill us, halt */
panic("Oops failed to kill thread");
}
-EXPORT_SYMBOL(abort);
void __init trap_init(void)
{
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1763,3 +1763,4 @@ __weak void abort(void)
/* if that doesn't kill us, halt */
panic("Oops failed to kill thread");
}
+EXPORT_SYMBOL(abort);
Patches currently in stable-queue which might be from akpm(a)linux-foundation.org are
queue-4.14/arch-define-weak-abort.patch
queue-4.14/kernel-exit.c-export-abort-to-modules.patch
This is a note to let you know that I've just added the patch titled
crypto: tcrypt - fix S/G table for test_aead_speed()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-tcrypt-fix-s-g-table-for-test_aead_speed.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1 Mon Sep 17 00:00:00 2001
From: Robert Baronescu <robert.baronescu(a)nxp.com>
Date: Tue, 10 Oct 2017 13:21:59 +0300
Subject: crypto: tcrypt - fix S/G table for test_aead_speed()
From: Robert Baronescu <robert.baronescu(a)nxp.com>
commit 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1 upstream.
In case buffer length is a multiple of PAGE_SIZE,
the S/G table is incorrectly generated.
Fix this by handling buflen = k * PAGE_SIZE separately.
Signed-off-by: Robert Baronescu <robert.baronescu(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Horia Geantă <horia.geanta(a)nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/tcrypt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -221,11 +221,13 @@ static void sg_init_aead(struct scatterl
}
sg_init_table(sg, np + 1);
- np--;
+ if (rem)
+ np--;
for (k = 0; k < np; k++)
sg_set_buf(&sg[k + 1], xbuf[k], PAGE_SIZE);
- sg_set_buf(&sg[k + 1], xbuf[k], rem);
+ if (rem)
+ sg_set_buf(&sg[k + 1], xbuf[k], rem);
}
static void test_aead_speed(const char *algo, int enc, unsigned int secs,
Patches currently in stable-queue which might be from robert.baronescu(a)nxp.com are
queue-4.14/crypto-tcrypt-fix-s-g-table-for-test_aead_speed.patch
This is a note to let you know that I've just added the patch titled
arch: define weak abort()
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:
arch-define-weak-abort.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 7c2c11b208be09c156573fc0076b7b3646e05219 Mon Sep 17 00:00:00 2001
From: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Date: Thu, 14 Dec 2017 15:33:19 -0800
Subject: arch: define weak abort()
From: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
commit 7c2c11b208be09c156573fc0076b7b3646e05219 upstream.
gcc toggle -fisolate-erroneous-paths-dereference (default at -O2
onwards) isolates faulty code paths such as null pointer access, divide
by zero etc. If gcc port doesnt implement __builtin_trap, an abort() is
generated which causes kernel link error.
In this case, gcc is generating abort due to 'divide by zero' in
lib/mpi/mpih-div.c.
Currently 'frv' and 'arc' are failing. Previously other arch was also
broken like m32r was fixed by commit d22e3d69ee1a ("m32r: fix build
failure").
Let's define this weak function which is common for all arch and fix the
problem permanently. We can even remove the arch specific 'abort' after
this is done.
Link: http://lkml.kernel.org/r/1513118956-8718-1-git-send-email-sudipm.mukherjee@…
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Cc: Alexey Brodkin <Alexey.Brodkin(a)synopsys.com>
Cc: Vineet Gupta <Vineet.Gupta1(a)synopsys.com>
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: Evgeniy Didin <Evgeniy.Didin(a)synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/exit.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1755,3 +1755,11 @@ Efault:
return -EFAULT;
}
#endif
+
+__weak void abort(void)
+{
+ BUG();
+
+ /* if that doesn't kill us, halt */
+ panic("Oops failed to kill thread");
+}
Patches currently in stable-queue which might be from sudipm.mukherjee(a)gmail.com are
queue-4.14/arch-define-weak-abort.patch
queue-4.14/kernel-exit.c-export-abort-to-modules.patch
Patch subject: "kernel/exit.c: export abort() to modules"
Commit ID: dc8635b78cd8
Reason: While building mpi.ko module with lastest stable Linux
v4.14.17 an error occured:
>ERROR: "abort" [lib/mpi/mpi.ko] undefined!
Kernel version: 4.14.x
The patch
regulator: stm32-vrefbuf: fix check on ready flag
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 f63248fac563125fd5a2f0bc780ce7a299872cab Mon Sep 17 00:00:00 2001
From: Fabrice Gasnier <fabrice.gasnier(a)st.com>
Date: Thu, 8 Feb 2018 14:43:05 +0100
Subject: [PATCH] regulator: stm32-vrefbuf: fix check on ready flag
stm32_vrefbuf_enable() wrongly checks VRR bit: 0 stands for not ready,
1 for ready. It currently checks the opposite.
This makes enable routine to exit immediately without waiting for ready
flag.
Fixes: 0cdbf481e927 ("regulator: Add support for stm32-vrefbuf")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/regulator/stm32-vrefbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/stm32-vrefbuf.c b/drivers/regulator/stm32-vrefbuf.c
index 72c8b3e1022b..e0a9c445ed67 100644
--- a/drivers/regulator/stm32-vrefbuf.c
+++ b/drivers/regulator/stm32-vrefbuf.c
@@ -51,7 +51,7 @@ static int stm32_vrefbuf_enable(struct regulator_dev *rdev)
* arbitrary timeout.
*/
ret = readl_poll_timeout(priv->base + STM32_VREFBUF_CSR, val,
- !(val & STM32_VRR), 650, 10000);
+ val & STM32_VRR, 650, 10000);
if (ret) {
dev_err(&rdev->dev, "stm32 vrefbuf timed out!\n");
val = readl_relaxed(priv->base + STM32_VREFBUF_CSR);
--
2.15.1
The patch
regmap: Fix reversed bounds check in regmap_raw_write()
has been applied to the regmap tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.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 f00e71091ab92eba52122332586c6ecaa9cd1a56 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Thu, 8 Feb 2018 10:23:44 +0300
Subject: [PATCH] regmap: Fix reversed bounds check in regmap_raw_write()
We're supposed to be checking that "val_len" is not too large but
instead we check if it is smaller than the max.
The only function affected would be regmap_i2c_smbus_i2c_write() in
drivers/base/regmap/regmap-i2c.c. Strangely that function has its own
limit check which returns an error if (count >= I2C_SMBUS_BLOCK_MAX) so
it doesn't look like it has ever been able to do anything except return
an error.
Fixes: c335931ed9d2 ("regmap: Add raw_write/read checks for max_raw_write/read sizes")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/base/regmap/regmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index ee302ccdfbc8..453116fd4362 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1831,7 +1831,7 @@ int regmap_raw_write(struct regmap *map, unsigned int reg,
return -EINVAL;
if (val_len % map->format.val_bytes)
return -EINVAL;
- if (map->max_raw_write && map->max_raw_write > val_len)
+ if (map->max_raw_write && map->max_raw_write < val_len)
return -E2BIG;
map->lock(map->lock_arg);
--
2.15.1
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses") optimized xenbus concurrent accesses but in doing so
broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in
charge of xenbus message exchange with the correct header and body. Now,
after the mentioned commit the replies received by application will no
longer have the header req_id echoed back as it was on request (see
specification below for reference), because that particular field is being
overwritten by kernel.
struct xsd_sockmsg
{
uint32_t type; /* XS_??? */
uint32_t req_id;/* Request identifier, echoed in daemon's response. */
uint32_t tx_id; /* Transaction id (0 if not related to a transaction). */
uint32_t len; /* Length of data following this. */
/* Generally followed by nul-terminated string(s). */
};
Before there was only one request at a time so req_id could simply be
forwarded back and forth. To allow simultaneous requests we need a
different req_id for each message thus kernel keeps a monotonic increasing
counter for this field and is written on every request irrespective of
userspace value.
Forwarding again the req_id on userspace requests is not a solution because
we would open the possibility of userspace-generated req_id colliding with
kernel ones. So this patch instead takes another route which is to
artificially keep user req_id while keeping the xenbus logic as is. We do
that by saving the original req_id before xs_send(), use the private kernel
counter as req_id and then once reply comes and was validated, we restore
back the original req_id.
Cc: <stable(a)vger.kernel.org> # 4.11
Fixes: fd8aa9095a ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Reported-by: Bhavesh Davda <bhavesh.davda(a)oracle.com>
Signed-off-by: Joao Martins <joao.m.martins(a)oracle.com>
Reviewed-by: Juergen Gross <jgross(a)suse.com>
---
Here's a link to a unit test (https://pastebin.com/N0kqNBnM) where req_id of
reply and response are being asserted each request. Without this patch
the assert will fail (e.g. try it with `./xswire_reqid_test name`). But
on <= v4.10 or >= v4.11 with the fix above, it will print domain name 10
times.
Changes since v2:
* Add Juergen's Reviewed-by
Changes since v1:
* Adjust commit message
(Comments from Juergen on IRC)
* Unilateraly save/restore req_id and remove xs_request_is_user()
* Initialize req_id for kernel callers
---
drivers/xen/xenbus/xenbus.h | 1 +
drivers/xen/xenbus/xenbus_comms.c | 1 +
drivers/xen/xenbus/xenbus_xs.c | 3 +++
3 files changed, 5 insertions(+)
diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 149c5e7efc89..092981171df1 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -76,6 +76,7 @@ struct xb_req_data {
struct list_head list;
wait_queue_head_t wq;
struct xsd_sockmsg msg;
+ uint32_t caller_req_id;
enum xsd_sockmsg_type type;
char *body;
const struct kvec *vec;
diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 5b081a01779d..d239fc3c5e3d 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -309,6 +309,7 @@ static int process_msg(void)
goto out;
if (req->state == xb_req_state_wait_reply) {
+ req->msg.req_id = req->caller_req_id;
req->msg.type = state.msg.type;
req->msg.len = state.msg.len;
req->body = state.body;
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 3e59590c7254..3f3b29398ab8 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -227,6 +227,8 @@ static void xs_send(struct xb_req_data *req, struct xsd_sockmsg *msg)
req->state = xb_req_state_queued;
init_waitqueue_head(&req->wq);
+ /* Save the caller req_id and restore it later in the reply */
+ req->caller_req_id = req->msg.req_id;
req->msg.req_id = xs_request_enter(req);
mutex_lock(&xb_write_mutex);
@@ -310,6 +312,7 @@ static void *xs_talkv(struct xenbus_transaction t,
req->num_vecs = num_vecs;
req->cb = xs_wake_up;
+ msg.req_id = 0;
msg.tx_id = t.id;
msg.type = type;
msg.len = 0;
--
2.11.0
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Al Viro reported:
For substring - sure, but what about something like "*a*b" and "a*b"?
AFAICS, filter_parse_regex() ends up with identical results in both
cases - MATCH_GLOB and *search = "a*b". And no way for the caller
to tell one from another.
Testing this with the following:
# cd /sys/kernel/tracing
# echo '*raw*lock' > set_ftrace_filter
bash: echo: write error: Invalid argument
With this patch:
# echo '*raw*lock' > set_ftrace_filter
# cat set_ftrace_filter
_raw_read_trylock
_raw_write_trylock
_raw_read_unlock
_raw_spin_unlock
_raw_write_unlock
_raw_spin_trylock
_raw_spin_lock
_raw_write_lock
_raw_read_lock
Al recommended not setting the search buffer to skip the first '*' unless we
know we are not using MATCH_GLOB. This implements his suggested logic.
Link: http://lkml.kernel.org/r/20180127170748.GF13338@ZenIV.linux.org.uk
Cc: stable(a)vger.kernel.org
Cc: Masami Hiramatsu <mhiramat(a)kernel.org>
Fixes: 60f1d5e3bac44 ("ftrace: Support full glob matching")
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Suggsted-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/trace/trace_events_filter.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
index 61e7f0678d33..a764aec3c9a1 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -400,7 +400,6 @@ enum regex_type filter_parse_regex(char *buff, int len, char **search, int *not)
for (i = 0; i < len; i++) {
if (buff[i] == '*') {
if (!i) {
- *search = buff + 1;
type = MATCH_END_ONLY;
} else if (i == len - 1) {
if (type == MATCH_END_ONLY)
@@ -410,14 +409,14 @@ enum regex_type filter_parse_regex(char *buff, int len, char **search, int *not)
buff[i] = 0;
break;
} else { /* pattern continues, use full glob */
- type = MATCH_GLOB;
- break;
+ return MATCH_GLOB;
}
} else if (strchr("[?\\", buff[i])) {
- type = MATCH_GLOB;
- break;
+ return MATCH_GLOB;
}
}
+ if (buff[0] == '*')
+ *search = buff + 1;
return type;
}
--
2.15.1
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
__unregister_ftrace_function_probe() will incorrectly parse the glob filter
because it resets the search variable that was setup by filter_parse_regex().
Al Viro reported this:
After that call of filter_parse_regex() we could have func_g.search not
equal to glob only if glob started with '!' or '*'. In the former case
we would've buggered off with -EINVAL (not = 1). In the latter we
would've set func_g.search equal to glob + 1, calculated the length of
that thing in func_g.len and proceeded to reset func_g.search back to
glob.
Suppose the glob is e.g. *foo*. We end up with
func_g.type = MATCH_MIDDLE_ONLY;
func_g.len = 3;
func_g.search = "*foo";
Feeding that to ftrace_match_record() will not do anything sane - we
will be looking for names containing "*foo" (->len is ignored for that
one).
Link: http://lkml.kernel.org/r/20180127031706.GE13338@ZenIV.linux.org.uk
Cc: stable(a)vger.kernel.org
Cc: Dmitry Safonov <0x7f454c46(a)gmail.com>
Fixes: 3ba009297149f ("ftrace: Introduce ftrace_glob structure")
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/trace/ftrace.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index dabd9d167d42..eac9ce2c57a2 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4456,7 +4456,6 @@ unregister_ftrace_function_probe_func(char *glob, struct trace_array *tr,
func_g.type = filter_parse_regex(glob, strlen(glob),
&func_g.search, ¬);
func_g.len = strlen(func_g.search);
- func_g.search = glob;
/* we do not support '!' for function probes */
if (WARN_ON(not))
--
2.15.1
Commit 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths")
removed the check for autotranslation from {set,clear}_foreign_p2m_mapping
but those are called by grant-table.c also on PVH/HVM guests.
Cc: <stable(a)vger.kernel.org> # 4.14
Fixes: 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths")
Signed-off-by: Simon Gaiser <simon(a)invisiblethingslab.com>
Reviewed-by: Juergen Gross <jgross(a)suse.com>
---
arch/x86/xen/p2m.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 13b4f19b9131..159a897151d6 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -694,6 +694,9 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
int i, ret = 0;
pte_t *pte;
+ if (xen_feature(XENFEAT_auto_translated_physmap))
+ return 0;
+
if (kmap_ops) {
ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
kmap_ops, count);
@@ -736,6 +739,9 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
{
int i, ret = 0;
+ if (xen_feature(XENFEAT_auto_translated_physmap))
+ return 0;
+
for (i = 0; i < count; i++) {
unsigned long mfn = __pfn_to_mfn(page_to_pfn(pages[i]));
unsigned long pfn = page_to_pfn(pages[i]);
--
2.15.1
From: Hans Verkuil <hansverk(a)cisco.com>
If the device is of type VFL_TYPE_SUBDEV then vdev->ioctl_ops
is NULL so the 'if (!ops->vidioc_query_ext_ctrl)' check would crash.
Add a test for !ops to the condition.
All sub-devices that have controls will use the control framework,
so they do not have an equivalent to ops->vidioc_query_ext_ctrl.
Returning false if ops is NULL is the correct thing to do here.
Fixes: b8c601e8af ("v4l2-compat-ioctl32.c: fix ctrl_is_pointer")
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Reported-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: <stable(a)vger.kernel.org> # for v4.15 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index bdb5c226d01c..5198c9eeb348 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -770,7 +770,7 @@ static inline bool ctrl_is_pointer(struct file *file, u32 id)
return ctrl && ctrl->is_ptr;
}
- if (!ops->vidioc_query_ext_ctrl)
+ if (!ops || !ops->vidioc_query_ext_ctrl)
return false;
return !ops->vidioc_query_ext_ctrl(file, fh, &qec) &&
--
2.15.1
This is a note to let you know that I've just added the patch titled
x86/uaccess: Use __uaccess_begin_nospec() and uaccess_try_nospec
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:02:49 -0800
Subject: x86/uaccess: Use __uaccess_begin_nospec() and uaccess_try_nospec
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit 304ec1b050310548db33063e567123fae8fd0301)
Quoting Linus:
I do think that it would be a good idea to very expressly document
the fact that it's not that the user access itself is unsafe. I do
agree that things like "get_user()" want to be protected, but not
because of any direct bugs or problems with get_user() and friends,
but simply because get_user() is an excellent source of a pointer
that is obviously controlled from a potentially attacking user
space. So it's a prime candidate for then finding _subsequent_
accesses that can then be used to perturb the cache.
__uaccess_begin_nospec() covers __get_user() and copy_from_iter() where the
limit check is far away from the user pointer de-reference. In those cases
a barrier_nospec() prevents speculation with a potential pointer to
privileged memory. uaccess_try_nospec covers get_user_try.
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Suggested-by: Andi Kleen <ak(a)linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: Kees Cook <keescook(a)chromium.org>
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727416953.33451.10508284228526170604.stgit@dwi…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/uaccess.h | 6 +++---
arch/x86/include/asm/uaccess_32.h | 12 ++++++------
arch/x86/include/asm/uaccess_64.h | 12 ++++++------
arch/x86/lib/usercopy_32.c | 4 ++--
4 files changed, 17 insertions(+), 17 deletions(-)
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -437,7 +437,7 @@ do { \
({ \
int __gu_err; \
__inttype(*(ptr)) __gu_val; \
- __uaccess_begin(); \
+ __uaccess_begin_nospec(); \
__get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT); \
__uaccess_end(); \
(x) = (__force __typeof__(*(ptr)))__gu_val; \
@@ -547,7 +547,7 @@ struct __large_struct { unsigned long bu
* get_user_ex(...);
* } get_user_catch(err)
*/
-#define get_user_try uaccess_try
+#define get_user_try uaccess_try_nospec
#define get_user_catch(err) uaccess_catch(err)
#define get_user_ex(x, ptr) do { \
@@ -582,7 +582,7 @@ extern void __cmpxchg_wrong_size(void)
__typeof__(ptr) __uval = (uval); \
__typeof__(*(ptr)) __old = (old); \
__typeof__(*(ptr)) __new = (new); \
- __uaccess_begin(); \
+ __uaccess_begin_nospec(); \
switch (size) { \
case 1: \
{ \
--- a/arch/x86/include/asm/uaccess_32.h
+++ b/arch/x86/include/asm/uaccess_32.h
@@ -102,17 +102,17 @@ __copy_from_user(void *to, const void __
switch (n) {
case 1:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_size(*(u8 *)to, from, 1, ret, 1);
__uaccess_end();
return ret;
case 2:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_size(*(u16 *)to, from, 2, ret, 2);
__uaccess_end();
return ret;
case 4:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_size(*(u32 *)to, from, 4, ret, 4);
__uaccess_end();
return ret;
@@ -130,17 +130,17 @@ static __always_inline unsigned long __c
switch (n) {
case 1:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_size(*(u8 *)to, from, 1, ret, 1);
__uaccess_end();
return ret;
case 2:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_size(*(u16 *)to, from, 2, ret, 2);
__uaccess_end();
return ret;
case 4:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_size(*(u32 *)to, from, 4, ret, 4);
__uaccess_end();
return ret;
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -59,31 +59,31 @@ int __copy_from_user_nocheck(void *dst,
return copy_user_generic(dst, (__force void *)src, size);
switch (size) {
case 1:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_asm(*(u8 *)dst, (u8 __user *)src,
ret, "b", "b", "=q", 1);
__uaccess_end();
return ret;
case 2:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_asm(*(u16 *)dst, (u16 __user *)src,
ret, "w", "w", "=r", 2);
__uaccess_end();
return ret;
case 4:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_asm(*(u32 *)dst, (u32 __user *)src,
ret, "l", "k", "=r", 4);
__uaccess_end();
return ret;
case 8:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_asm(*(u64 *)dst, (u64 __user *)src,
ret, "q", "", "=r", 8);
__uaccess_end();
return ret;
case 10:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_asm(*(u64 *)dst, (u64 __user *)src,
ret, "q", "", "=r", 10);
if (likely(!ret))
@@ -93,7 +93,7 @@ int __copy_from_user_nocheck(void *dst,
__uaccess_end();
return ret;
case 16:
- __uaccess_begin();
+ __uaccess_begin_nospec();
__get_user_asm(*(u64 *)dst, (u64 __user *)src,
ret, "q", "", "=r", 16);
if (likely(!ret))
--- a/arch/x86/lib/usercopy_32.c
+++ b/arch/x86/lib/usercopy_32.c
@@ -570,7 +570,7 @@ do { \
unsigned long __copy_to_user_ll(void __user *to, const void *from,
unsigned long n)
{
- __uaccess_begin();
+ __uaccess_begin_nospec();
if (movsl_is_ok(to, from, n))
__copy_user(to, from, n);
else
@@ -627,7 +627,7 @@ EXPORT_SYMBOL(__copy_from_user_ll_nocach
unsigned long __copy_from_user_ll_nocache_nozero(void *to, const void __user *from,
unsigned long n)
{
- __uaccess_begin();
+ __uaccess_begin_nospec();
#ifdef CONFIG_X86_INTEL_USERCOPY
if (n > 64 && static_cpu_has(X86_FEATURE_XMM2))
n = __copy_user_intel_nocache(to, from, n);
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86/usercopy: Replace open coded stac/clac with __uaccess_{begin, end}
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:02:44 -0800
Subject: x86/usercopy: Replace open coded stac/clac with __uaccess_{begin, end}
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit b5c4ae4f35325d520b230bab6eb3310613b72ac1)
In preparation for converting some __uaccess_begin() instances to
__uacess_begin_nospec(), make sure all 'from user' uaccess paths are
using the _begin(), _end() helpers rather than open-coded stac() and
clac().
No functional changes.
Suggested-by: Ingo Molnar <mingo(a)redhat.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: Tom Lendacky <thomas.lendacky(a)amd.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: torvalds(a)linux-foundation.org
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727416438.33451.17309465232057176966.stgit@dwi…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/lib/usercopy_32.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/x86/lib/usercopy_32.c
+++ b/arch/x86/lib/usercopy_32.c
@@ -570,12 +570,12 @@ do { \
unsigned long __copy_to_user_ll(void __user *to, const void *from,
unsigned long n)
{
- stac();
+ __uaccess_begin();
if (movsl_is_ok(to, from, n))
__copy_user(to, from, n);
else
n = __copy_user_intel(to, from, n);
- clac();
+ __uaccess_end();
return n;
}
EXPORT_SYMBOL(__copy_to_user_ll);
@@ -627,7 +627,7 @@ EXPORT_SYMBOL(__copy_from_user_ll_nocach
unsigned long __copy_from_user_ll_nocache_nozero(void *to, const void __user *from,
unsigned long n)
{
- stac();
+ __uaccess_begin();
#ifdef CONFIG_X86_INTEL_USERCOPY
if (n > 64 && static_cpu_has(X86_FEATURE_XMM2))
n = __copy_user_intel_nocache(to, from, n);
@@ -636,7 +636,7 @@ unsigned long __copy_from_user_ll_nocach
#else
__copy_user(to, from, n);
#endif
- clac();
+ __uaccess_end();
return n;
}
EXPORT_SYMBOL(__copy_from_user_ll_nocache_nozero);
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86/syscall: Sanitize syscall table de-references under speculation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-syscall-sanitize-syscall-table-de-references-under-speculation.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:02:59 -0800
Subject: x86/syscall: Sanitize syscall table de-references under speculation
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit 2fbd7af5af8665d18bcefae3e9700be07e22b681)
The syscall table base is a user controlled function pointer in kernel
space. Use array_index_nospec() to prevent any out of bounds speculation.
While retpoline prevents speculating into a userspace directed target it
does not stop the pointer de-reference, the concern is leaking memory
relative to the syscall table base, by observing instruction cache
behavior.
Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727417984.33451.1216731042505722161.stgit@dwil…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/entry/common.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -20,6 +20,7 @@
#include <linux/export.h>
#include <linux/context_tracking.h>
#include <linux/user-return-notifier.h>
+#include <linux/nospec.h>
#include <linux/uprobes.h>
#include <asm/desc.h>
@@ -277,7 +278,8 @@ __visible void do_syscall_64(struct pt_r
* regs->orig_ax, which changes the behavior of some syscalls.
*/
if (likely((nr & __SYSCALL_MASK) < NR_syscalls)) {
- regs->ax = sys_call_table[nr & __SYSCALL_MASK](
+ nr = array_index_nospec(nr & __SYSCALL_MASK, NR_syscalls);
+ regs->ax = sys_call_table[nr](
regs->di, regs->si, regs->dx,
regs->r10, regs->r8, regs->r9);
}
@@ -313,6 +315,7 @@ static __always_inline void do_syscall_3
}
if (likely(nr < IA32_NR_syscalls)) {
+ nr = array_index_nospec(nr, IA32_NR_syscalls);
/*
* It's possible that a 32-bit syscall implementation
* takes a 64-bit parameter but nonetheless assumes that
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-speculation-fix-typo-ibrs_att-which-should-be-ibrs_all.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 Thu Feb 8 03:33:09 CET 2018
From: Darren Kenny <darren.kenny(a)oracle.com>
Date: Fri, 2 Feb 2018 19:12:20 +0000
Subject: x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL
From: Darren Kenny <darren.kenny(a)oracle.com>
(cherry picked from commit af189c95a371b59f493dbe0f50c0a09724868881)
Fixes: 117cc7a908c83 ("x86/retpoline: Fill return stack buffer on vmexit")
Signed-off-by: Darren Kenny <darren.kenny(a)oracle.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Tom Lendacky <thomas.lendacky(a)amd.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: David Woodhouse <dwmw(a)amazon.co.uk>
Link: https://lkml.kernel.org/r/20180202191220.blvgkgutojecxr3b@starbug-vm.ie.ora…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/nospec-branch.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -150,7 +150,7 @@ extern char __indirect_thunk_end[];
* On VMEXIT we must ensure that no RSB predictions learned in the guest
* can be followed in the host, by overwriting the RSB completely. Both
* retpoline and IBRS mitigations for Spectre v2 need this; only on future
- * CPUs with IBRS_ATT *might* it be avoided.
+ * CPUs with IBRS_ALL *might* it be avoided.
*/
static inline void vmexit_fill_RSB(void)
{
Patches currently in stable-queue which might be from darren.kenny(a)oracle.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-speculation-fix-typo-ibrs_att-which-should-be-ibrs_all.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
This is a note to let you know that I've just added the patch titled
x86/spectre: Report get_user mitigation for spectre_v1
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-spectre-report-get_user-mitigation-for-spectre_v1.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:03:21 -0800
Subject: x86/spectre: Report get_user mitigation for spectre_v1
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit edfbae53dab8348fca778531be9f4855d2ca0360)
Reflect the presence of get_user(), __get_user(), and 'syscall' protections
in sysfs. The expectation is that new and better tooling will allow the
kernel to grow more usages of array_index_nospec(), for now, only claim
mitigation for __user pointer de-references.
Reported-by: Jiri Slaby <jslaby(a)suse.cz>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: torvalds(a)linux-foundation.org
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727420158.33451.11658324346540434635.stgit@dwi…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/bugs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -296,7 +296,7 @@ ssize_t cpu_show_spectre_v1(struct devic
{
if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V1))
return sprintf(buf, "Not affected\n");
- return sprintf(buf, "Vulnerable\n");
+ return sprintf(buf, "Mitigation: __user pointer sanitization\n");
}
ssize_t cpu_show_spectre_v2(struct device *dev,
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86/spectre: Fix spelling mistake: "vunerable"-> "vulnerable"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-spectre-fix-spelling-mistake-vunerable-vulnerable.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 Thu Feb 8 03:32:24 CET 2018
From: Colin Ian King <colin.king(a)canonical.com>
Date: Tue, 30 Jan 2018 19:32:18 +0000
Subject: x86/spectre: Fix spelling mistake: "vunerable"-> "vulnerable"
From: Colin Ian King <colin.king(a)canonical.com>
(cherry picked from commit e698dcdfcda41efd0984de539767b4cddd235f1e)
Trivial fix to spelling mistake in pr_err error message text.
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: kernel-janitors(a)vger.kernel.org
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: David Woodhouse <dwmw(a)amazon.co.uk>
Link: https://lkml.kernel.org/r/20180130193218.9271-1-colin.king@canonical.com
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/bugs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -102,7 +102,7 @@ bool retpoline_module_ok(bool has_retpol
if (spectre_v2_enabled == SPECTRE_V2_NONE || has_retpoline)
return true;
- pr_err("System may be vunerable to spectre v2\n");
+ pr_err("System may be vulnerable to spectre v2\n");
spectre_v2_bad_module = true;
return false;
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.9/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
This is a note to let you know that I've just added the patch titled
x86/spectre: Check CONFIG_RETPOLINE in command line parser
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-spectre-check-config_retpoline-in-command-line-parser.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 Thu Feb 8 03:30:27 CET 2018
From: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
Date: Tue, 30 Jan 2018 14:13:50 +0800
Subject: x86/spectre: Check CONFIG_RETPOLINE in command line parser
From: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
(cherry picked from commit 9471eee9186a46893726e22ebb54cade3f9bc043)
The spectre_v2 option 'auto' does not check whether CONFIG_RETPOLINE is
enabled. As a consequence it fails to emit the appropriate warning and sets
feature flags which have no effect at all.
Add the missing IS_ENABLED() check.
Fixes: da285121560e ("x86/spectre: Add boot time option to select Spectre v2 mitigation")
Signed-off-by: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: ak(a)linux.intel.com
Cc: peterz(a)infradead.org
Cc: Tomohiro" <misono.tomohiro(a)jp.fujitsu.com>
Cc: dave.hansen(a)intel.com
Cc: bp(a)alien8.de
Cc: arjan(a)linux.intel.com
Cc: dwmw(a)amazon.co.uk
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/f5892721-7528-3647-08fb-f8d10e65ad87@cn.fujitsu.c…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/bugs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -212,10 +212,10 @@ static void __init spectre_v2_select_mit
return;
case SPECTRE_V2_CMD_FORCE:
- /* FALLTRHU */
case SPECTRE_V2_CMD_AUTO:
- goto retpoline_auto;
-
+ if (IS_ENABLED(CONFIG_RETPOLINE))
+ goto retpoline_auto;
+ break;
case SPECTRE_V2_CMD_RETPOLINE_AMD:
if (IS_ENABLED(CONFIG_RETPOLINE))
goto retpoline_amd;
Patches currently in stable-queue which might be from douly.fnst(a)cn.fujitsu.com are
queue-4.9/x86-spectre-check-config_retpoline-in-command-line-parser.patch
This is a note to let you know that I've just added the patch titled
x86/retpoline: Simplify vmexit_fill_RSB()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-retpoline-simplify-vmexit_fill_rsb.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 Thu Feb 8 03:30:27 CET 2018
From: Borislav Petkov <bp(a)alien8.de>
Date: Sat, 27 Jan 2018 16:24:33 +0000
Subject: x86/retpoline: Simplify vmexit_fill_RSB()
From: Borislav Petkov <bp(a)alien8.de>
(cherry picked from commit 1dde7415e99933bb7293d6b2843752cbdb43ec11)
Simplify it to call an asm-function instead of pasting 41 insn bytes at
every call site. Also, add alignment to the macro as suggested here:
https://support.google.com/faqs/answer/7625886
[dwmw2: Clean up comments, let it clobber %ebx and just tell the compiler]
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: ak(a)linux.intel.com
Cc: dave.hansen(a)intel.com
Cc: karahmed(a)amazon.de
Cc: arjan(a)linux.intel.com
Cc: torvalds(a)linux-foundation.org
Cc: peterz(a)infradead.org
Cc: bp(a)alien8.de
Cc: pbonzini(a)redhat.com
Cc: tim.c.chen(a)linux.intel.com
Cc: gregkh(a)linux-foundation.org
Link: https://lkml.kernel.org/r/1517070274-12128-3-git-send-email-dwmw@amazon.co.…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/entry/entry_32.S | 3 -
arch/x86/entry/entry_64.S | 3 -
arch/x86/include/asm/asm-prototypes.h | 3 +
arch/x86/include/asm/nospec-branch.h | 70 +++-------------------------------
arch/x86/lib/Makefile | 1
arch/x86/lib/retpoline.S | 56 +++++++++++++++++++++++++++
6 files changed, 71 insertions(+), 65 deletions(-)
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -237,7 +237,8 @@ ENTRY(__switch_to_asm)
* exist, overwrite the RSB with entries which capture
* speculative execution to prevent attack.
*/
- FILL_RETURN_BUFFER %ebx, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW
+ /* Clobbers %ebx */
+ FILL_RETURN_BUFFER RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW
#endif
/* restore callee-saved registers */
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -435,7 +435,8 @@ ENTRY(__switch_to_asm)
* exist, overwrite the RSB with entries which capture
* speculative execution to prevent attack.
*/
- FILL_RETURN_BUFFER %r12, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW
+ /* Clobbers %rbx */
+ FILL_RETURN_BUFFER RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW
#endif
/* restore callee-saved registers */
--- a/arch/x86/include/asm/asm-prototypes.h
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -37,4 +37,7 @@ INDIRECT_THUNK(dx)
INDIRECT_THUNK(si)
INDIRECT_THUNK(di)
INDIRECT_THUNK(bp)
+asmlinkage void __fill_rsb(void);
+asmlinkage void __clear_rsb(void);
+
#endif /* CONFIG_RETPOLINE */
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -7,50 +7,6 @@
#include <asm/alternative-asm.h>
#include <asm/cpufeatures.h>
-/*
- * Fill the CPU return stack buffer.
- *
- * Each entry in the RSB, if used for a speculative 'ret', contains an
- * infinite 'pause; lfence; jmp' loop to capture speculative execution.
- *
- * This is required in various cases for retpoline and IBRS-based
- * mitigations for the Spectre variant 2 vulnerability. Sometimes to
- * eliminate potentially bogus entries from the RSB, and sometimes
- * purely to ensure that it doesn't get empty, which on some CPUs would
- * allow predictions from other (unwanted!) sources to be used.
- *
- * We define a CPP macro such that it can be used from both .S files and
- * inline assembly. It's possible to do a .macro and then include that
- * from C via asm(".include <asm/nospec-branch.h>") but let's not go there.
- */
-
-#define RSB_CLEAR_LOOPS 32 /* To forcibly overwrite all entries */
-#define RSB_FILL_LOOPS 16 /* To avoid underflow */
-
-/*
- * Google experimented with loop-unrolling and this turned out to be
- * the optimal version — two calls, each with their own speculation
- * trap should their return address end up getting used, in a loop.
- */
-#define __FILL_RETURN_BUFFER(reg, nr, sp) \
- mov $(nr/2), reg; \
-771: \
- call 772f; \
-773: /* speculation trap */ \
- pause; \
- lfence; \
- jmp 773b; \
-772: \
- call 774f; \
-775: /* speculation trap */ \
- pause; \
- lfence; \
- jmp 775b; \
-774: \
- dec reg; \
- jnz 771b; \
- add $(BITS_PER_LONG/8) * nr, sp;
-
#ifdef __ASSEMBLY__
/*
@@ -121,17 +77,10 @@
#endif
.endm
- /*
- * A simpler FILL_RETURN_BUFFER macro. Don't make people use the CPP
- * monstrosity above, manually.
- */
-.macro FILL_RETURN_BUFFER reg:req nr:req ftr:req
+/* This clobbers the BX register */
+.macro FILL_RETURN_BUFFER nr:req ftr:req
#ifdef CONFIG_RETPOLINE
- ANNOTATE_NOSPEC_ALTERNATIVE
- ALTERNATIVE "jmp .Lskip_rsb_\@", \
- __stringify(__FILL_RETURN_BUFFER(\reg,\nr,%_ASM_SP)) \
- \ftr
-.Lskip_rsb_\@:
+ ALTERNATIVE "", "call __clear_rsb", \ftr
#endif
.endm
@@ -206,15 +155,10 @@ extern char __indirect_thunk_end[];
static inline void vmexit_fill_RSB(void)
{
#ifdef CONFIG_RETPOLINE
- unsigned long loops;
-
- asm volatile (ANNOTATE_NOSPEC_ALTERNATIVE
- ALTERNATIVE("jmp 910f",
- __stringify(__FILL_RETURN_BUFFER(%0, RSB_CLEAR_LOOPS, %1)),
- X86_FEATURE_RETPOLINE)
- "910:"
- : "=r" (loops), ASM_CALL_CONSTRAINT
- : : "memory" );
+ alternative_input("",
+ "call __fill_rsb",
+ X86_FEATURE_RETPOLINE,
+ ASM_NO_INPUT_CLOBBER(_ASM_BX, "memory"));
#endif
}
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -26,6 +26,7 @@ lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) +=
lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o
lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
lib-$(CONFIG_RETPOLINE) += retpoline.o
+OBJECT_FILES_NON_STANDARD_retpoline.o :=y
obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
--- a/arch/x86/lib/retpoline.S
+++ b/arch/x86/lib/retpoline.S
@@ -7,6 +7,7 @@
#include <asm/alternative-asm.h>
#include <asm/export.h>
#include <asm/nospec-branch.h>
+#include <asm/bitsperlong.h>
.macro THUNK reg
.section .text.__x86.indirect_thunk
@@ -46,3 +47,58 @@ GENERATE_THUNK(r13)
GENERATE_THUNK(r14)
GENERATE_THUNK(r15)
#endif
+
+/*
+ * Fill the CPU return stack buffer.
+ *
+ * Each entry in the RSB, if used for a speculative 'ret', contains an
+ * infinite 'pause; lfence; jmp' loop to capture speculative execution.
+ *
+ * This is required in various cases for retpoline and IBRS-based
+ * mitigations for the Spectre variant 2 vulnerability. Sometimes to
+ * eliminate potentially bogus entries from the RSB, and sometimes
+ * purely to ensure that it doesn't get empty, which on some CPUs would
+ * allow predictions from other (unwanted!) sources to be used.
+ *
+ * Google experimented with loop-unrolling and this turned out to be
+ * the optimal version - two calls, each with their own speculation
+ * trap should their return address end up getting used, in a loop.
+ */
+.macro STUFF_RSB nr:req sp:req
+ mov $(\nr / 2), %_ASM_BX
+ .align 16
+771:
+ call 772f
+773: /* speculation trap */
+ pause
+ lfence
+ jmp 773b
+ .align 16
+772:
+ call 774f
+775: /* speculation trap */
+ pause
+ lfence
+ jmp 775b
+ .align 16
+774:
+ dec %_ASM_BX
+ jnz 771b
+ add $((BITS_PER_LONG/8) * \nr), \sp
+.endm
+
+#define RSB_FILL_LOOPS 16 /* To avoid underflow */
+
+ENTRY(__fill_rsb)
+ STUFF_RSB RSB_FILL_LOOPS, %_ASM_SP
+ ret
+END(__fill_rsb)
+EXPORT_SYMBOL_GPL(__fill_rsb)
+
+#define RSB_CLEAR_LOOPS 32 /* To forcibly overwrite all entries */
+
+ENTRY(__clear_rsb)
+ STUFF_RSB RSB_CLEAR_LOOPS, %_ASM_SP
+ ret
+END(__clear_rsb)
+EXPORT_SYMBOL_GPL(__clear_rsb)
Patches currently in stable-queue which might be from bp(a)alien8.de are
queue-4.9/x86-entry-64-push-extra-regs-right-away.patch
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-retpoline-simplify-vmexit_fill_rsb.patch
queue-4.9/x86-cpufeatures-clean-up-spectre-v2-related-cpuid-flags.patch
queue-4.9/x86-asm-move-status-from-thread_struct-to-thread_info.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch
queue-4.9/x86-entry-64-remove-the-syscall64-fast-path.patch
queue-4.9/x86-cpufeature-blacklist-spec_ctrl-pred_cmd-on-early-spectre-v2-microcodes.patch
queue-4.9/x86-nospec-fix-header-guards-names.patch
queue-4.9/x86-retpoline-avoid-retpolines-for-built-in-__init-functions.patch
queue-4.9/x86-cpu-bugs-make-retpoline-module-warning-conditional.patch
queue-4.9/x86-spectre-check-config_retpoline-in-command-line-parser.patch
queue-4.9/x86-alternative-print-unadorned-pointers.patch
queue-4.9/x86-cpuid-fix-up-virtual-ibrs-ibpb-stibp-feature-bits-on-intel.patch
queue-4.9/x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
queue-4.9/x86-spectre-simplify-spectre_v2-command-line-parsing.patch
queue-4.9/x86-msr-add-definitions-for-new-speculation-control-msrs.patch
queue-4.9/x86-speculation-add-basic-ibpb-indirect-branch-prediction-barrier-support.patch
queue-4.9/x86-speculation-fix-typo-ibrs_att-which-should-be-ibrs_all.patch
queue-4.9/x86-bugs-drop-one-mitigation-from-dmesg.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
This is a note to let you know that I've just added the patch titled
x86/retpoline: Avoid retpolines for built-in __init functions
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-retpoline-avoid-retpolines-for-built-in-__init-functions.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 Thu Feb 8 03:32:24 CET 2018
From: David Woodhouse <dwmw(a)amazon.co.uk>
Date: Thu, 1 Feb 2018 11:27:20 +0000
Subject: x86/retpoline: Avoid retpolines for built-in __init functions
From: David Woodhouse <dwmw(a)amazon.co.uk>
(cherry picked from commit 66f793099a636862a71c59d4a6ba91387b155e0c)
There's no point in building init code with retpolines, since it runs before
any potentially hostile userspace does. And before the retpoline is actually
ALTERNATIVEd into place, for much of it.
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: karahmed(a)amazon.de
Cc: peterz(a)infradead.org
Cc: bp(a)alien8.de
Link: https://lkml.kernel.org/r/1517484441-1420-2-git-send-email-dwmw@amazon.co.uk
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/init.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -4,6 +4,13 @@
#include <linux/compiler.h>
#include <linux/types.h>
+/* Built-in __init functions needn't be compiled with retpoline */
+#if defined(RETPOLINE) && !defined(MODULE)
+#define __noretpoline __attribute__((indirect_branch("keep")))
+#else
+#define __noretpoline
+#endif
+
/* These macros are used to mark some functions or
* initialized data (doesn't apply to uninitialized data)
* as `initialization' functions. The kernel can take this
@@ -39,7 +46,7 @@
/* These are for everybody (although not all archs will actually
discard it in modules) */
-#define __init __section(.init.text) __cold notrace __latent_entropy
+#define __init __section(.init.text) __cold notrace __latent_entropy __noretpoline
#define __initdata __section(.init.data)
#define __initconst __section(.init.rodata)
#define __exitdata __section(.exit.data)
Patches currently in stable-queue which might be from dwmw(a)amazon.co.uk are
queue-4.9/x86-entry-64-push-extra-regs-right-away.patch
queue-4.9/kvm-vmx-introduce-alloc_loaded_vmcs.patch
queue-4.9/kvm-nvmx-eliminate-vmcs02-pool.patch
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-retpoline-simplify-vmexit_fill_rsb.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/x86-cpufeatures-clean-up-spectre-v2-related-cpuid-flags.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/x86-asm-move-status-from-thread_struct-to-thread_info.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-entry-64-remove-the-syscall64-fast-path.patch
queue-4.9/x86-cpufeature-blacklist-spec_ctrl-pred_cmd-on-early-spectre-v2-microcodes.patch
queue-4.9/x86-nospec-fix-header-guards-names.patch
queue-4.9/x86-retpoline-avoid-retpolines-for-built-in-__init-functions.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-cpu-bugs-make-retpoline-module-warning-conditional.patch
queue-4.9/x86-spectre-check-config_retpoline-in-command-line-parser.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/x86-alternative-print-unadorned-pointers.patch
queue-4.9/x86-cpuid-fix-up-virtual-ibrs-ibpb-stibp-feature-bits-on-intel.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
queue-4.9/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.9/module-retpoline-warn-about-missing-retpoline-in-module.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/kvm-nvmx-vmx_complete_nested_posted_interrupt-can-t-fail.patch
queue-4.9/x86-spectre-simplify-spectre_v2-command-line-parsing.patch
queue-4.9/x86-msr-add-definitions-for-new-speculation-control-msrs.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/kvm-vmx-make-msr-bitmaps-per-vcpu.patch
queue-4.9/x86-speculation-add-basic-ibpb-indirect-branch-prediction-barrier-support.patch
queue-4.9/kvm-nvmx-mark-vmcs12-pages-dirty-on-l2-exit.patch
queue-4.9/x86-pti-mark-constant-arrays-as-__initconst.patch
queue-4.9/x86-speculation-fix-typo-ibrs_att-which-should-be-ibrs_all.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-bugs-drop-one-mitigation-from-dmesg.patch
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86/paravirt: Remove 'noreplace-paravirt' cmdline option
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-paravirt-remove-noreplace-paravirt-cmdline-option.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 Thu Feb 8 03:32:24 CET 2018
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
Date: Tue, 30 Jan 2018 22:13:33 -0600
Subject: x86/paravirt: Remove 'noreplace-paravirt' cmdline option
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
(cherry picked from commit 12c69f1e94c89d40696e83804dd2f0965b5250cd)
The 'noreplace-paravirt' option disables paravirt patching, leaving the
original pv indirect calls in place.
That's highly incompatible with retpolines, unless we want to uglify
paravirt even further and convert the paravirt calls to retpolines.
As far as I can tell, the option doesn't seem to be useful for much
other than introducing surprising corner cases and making the kernel
vulnerable to Spectre v2. It was probably a debug option from the early
paravirt days. So just remove it.
Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Juergen Gross <jgross(a)suse.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Ashok Raj <ashok.raj(a)intel.com>
Cc: Greg KH <gregkh(a)linuxfoundation.org>
Cc: Jun Nakajima <jun.nakajima(a)intel.com>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: Rusty Russell <rusty(a)rustcorp.com.au>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Asit Mallick <asit.k.mallick(a)intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Jason Baron <jbaron(a)akamai.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Alok Kataria <akataria(a)vmware.com>
Cc: Arjan Van De Ven <arjan.van.de.ven(a)intel.com>
Cc: David Woodhouse <dwmw2(a)infradead.org>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Link: https://lkml.kernel.org/r/20180131041333.2x6blhxirc2kclrq@treble
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/kernel-parameters.txt | 2 --
arch/x86/kernel/alternative.c | 14 --------------
2 files changed, 16 deletions(-)
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2805,8 +2805,6 @@ bytes respectively. Such letter suffixes
norandmaps Don't use address space randomization. Equivalent to
echo 0 > /proc/sys/kernel/randomize_va_space
- noreplace-paravirt [X86,IA-64,PV_OPS] Don't patch paravirt_ops
-
noreplace-smp [X86-32,SMP] Don't replace SMP instructions
with UP alternatives
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -46,17 +46,6 @@ static int __init setup_noreplace_smp(ch
}
__setup("noreplace-smp", setup_noreplace_smp);
-#ifdef CONFIG_PARAVIRT
-static int __initdata_or_module noreplace_paravirt = 0;
-
-static int __init setup_noreplace_paravirt(char *str)
-{
- noreplace_paravirt = 1;
- return 1;
-}
-__setup("noreplace-paravirt", setup_noreplace_paravirt);
-#endif
-
#define DPRINTK(fmt, args...) \
do { \
if (debug_alternative) \
@@ -588,9 +577,6 @@ void __init_or_module apply_paravirt(str
struct paravirt_patch_site *p;
char insnbuf[MAX_PATCH_LEN];
- if (noreplace_paravirt)
- return;
-
for (p = start; p < end; p++) {
unsigned int used;
Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-nospec-fix-header-guards-names.patch
queue-4.9/x86-asm-fix-inline-asm-call-constraints-for-gcc-4.4.patch
queue-4.9/x86-alternative-print-unadorned-pointers.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-bugs-drop-one-mitigation-from-dmesg.patch
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
This is a note to let you know that I've just added the patch titled
x86/pti: Mark constant arrays as __initconst
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-pti-mark-constant-arrays-as-__initconst.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 Thu Feb 8 03:33:09 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 2 Feb 2018 22:39:23 +0100
Subject: x86/pti: Mark constant arrays as __initconst
From: Arnd Bergmann <arnd(a)arndb.de>
(cherry picked from commit 4bf5d56d429cbc96c23d809a08f63cd29e1a702e)
I'm seeing build failures from the two newly introduced arrays that
are marked 'const' and '__initdata', which are mutually exclusive:
arch/x86/kernel/cpu/common.c:882:43: error: 'cpu_no_speculation' causes a section type conflict with 'e820_table_firmware_init'
arch/x86/kernel/cpu/common.c:895:43: error: 'cpu_no_meltdown' causes a section type conflict with 'e820_table_firmware_init'
The correct annotation is __initconst.
Fixes: fec9434a12f3 ("x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: Thomas Garnier <thgarnie(a)google.com>
Cc: David Woodhouse <dwmw(a)amazon.co.uk>
Link: https://lkml.kernel.org/r/20180202213959.611210-1-arnd@arndb.de
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -861,7 +861,7 @@ static void identify_cpu_without_cpuid(s
#endif
}
-static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
+static const __initconst struct x86_cpu_id cpu_no_speculation[] = {
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY },
@@ -874,7 +874,7 @@ static const __initdata struct x86_cpu_i
{}
};
-static const __initdata struct x86_cpu_id cpu_no_meltdown[] = {
+static const __initconst struct x86_cpu_id cpu_no_meltdown[] = {
{ X86_VENDOR_AMD },
{}
};
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/auxdisplay-img-ascii-lcd-add-missing-module_description-author-license.patch
queue-4.9/x86-asm-fix-inline-asm-call-constraints-for-gcc-4.4.patch
queue-4.9/x86-pti-mark-constant-arrays-as-__initconst.patch
This is a note to let you know that I've just added the patch titled
x86/nospec: Fix header guards names
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-nospec-fix-header-guards-names.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 Thu Feb 8 03:30:27 CET 2018
From: Borislav Petkov <bp(a)suse.de>
Date: Fri, 26 Jan 2018 13:11:37 +0100
Subject: x86/nospec: Fix header guards names
From: Borislav Petkov <bp(a)suse.de>
(cherry picked from commit 7a32fc51ca938e67974cbb9db31e1a43f98345a9)
... to adhere to the _ASM_X86_ naming scheme.
No functional change.
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: riel(a)redhat.com
Cc: ak(a)linux.intel.com
Cc: peterz(a)infradead.org
Cc: David Woodhouse <dwmw2(a)infradead.org>
Cc: jikos(a)kernel.org
Cc: luto(a)amacapital.net
Cc: dave.hansen(a)intel.com
Cc: torvalds(a)linux-foundation.org
Cc: keescook(a)google.com
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: tim.c.chen(a)linux.intel.com
Cc: gregkh(a)linux-foundation.org
Cc: pjt(a)google.com
Link: https://lkml.kernel.org/r/20180126121139.31959-3-bp@alien8.de
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/nospec-branch.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __NOSPEC_BRANCH_H__
-#define __NOSPEC_BRANCH_H__
+#ifndef _ASM_X86_NOSPEC_BRANCH_H_
+#define _ASM_X86_NOSPEC_BRANCH_H_
#include <asm/alternative.h>
#include <asm/alternative-asm.h>
@@ -232,4 +232,4 @@ static inline void indirect_branch_predi
}
#endif /* __ASSEMBLY__ */
-#endif /* __NOSPEC_BRANCH_H__ */
+#endif /* _ASM_X86_NOSPEC_BRANCH_H_ */
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-retpoline-simplify-vmexit_fill_rsb.patch
queue-4.9/x86-cpufeatures-clean-up-spectre-v2-related-cpuid-flags.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch
queue-4.9/x86-nospec-fix-header-guards-names.patch
queue-4.9/x86-alternative-print-unadorned-pointers.patch
queue-4.9/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.9/x86-pti-mark-constant-arrays-as-__initconst.patch
queue-4.9/x86-bugs-drop-one-mitigation-from-dmesg.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
This is a note to let you know that I've just added the patch titled
x86/kvm: Update spectre-v1 mitigation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-kvm-update-spectre-v1-mitigation.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Wed, 31 Jan 2018 17:47:03 -0800
Subject: x86/kvm: Update spectre-v1 mitigation
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit 085331dfc6bbe3501fb936e657331ca943827600)
Commit 75f139aaf896 "KVM: x86: Add memory barrier on vmcs field lookup"
added a raw 'asm("lfence");' to prevent a bounds check bypass of
'vmcs_field_to_offset_table'.
The lfence can be avoided in this path by using the array_index_nospec()
helper designed for these types of fixes.
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Andrew Honig <ahonig(a)google.com>
Cc: kvm(a)vger.kernel.org
Cc: Jim Mattson <jmattson(a)google.com>
Link: https://lkml.kernel.org/r/151744959670.6342.3001723920950249067.stgit@dwill…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -33,6 +33,7 @@
#include <linux/slab.h>
#include <linux/tboot.h>
#include <linux/hrtimer.h>
+#include <linux/nospec.h>
#include "kvm_cache_regs.h"
#include "x86.h"
@@ -856,21 +857,18 @@ static const unsigned short vmcs_field_t
static inline short vmcs_field_to_offset(unsigned long field)
{
- BUILD_BUG_ON(ARRAY_SIZE(vmcs_field_to_offset_table) > SHRT_MAX);
+ const size_t size = ARRAY_SIZE(vmcs_field_to_offset_table);
+ unsigned short offset;
- if (field >= ARRAY_SIZE(vmcs_field_to_offset_table))
+ BUILD_BUG_ON(size > SHRT_MAX);
+ if (field >= size)
return -ENOENT;
- /*
- * FIXME: Mitigation for CVE-2017-5753. To be replaced with a
- * generic mechanism.
- */
- asm("lfence");
-
- if (vmcs_field_to_offset_table[field] == 0)
+ field = array_index_nospec(field, size);
+ offset = vmcs_field_to_offset_table[field];
+ if (offset == 0)
return -ENOENT;
-
- return vmcs_field_to_offset_table[field];
+ return offset;
}
static inline struct vmcs12 *get_vmcs12(struct kvm_vcpu *vcpu)
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86: Introduce barrier_nospec
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-introduce-barrier_nospec.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:02:33 -0800
Subject: x86: Introduce barrier_nospec
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit b3d7ad85b80bbc404635dca80f5b129f6242bc7a)
Rename the open coded form of this instruction sequence from
rdtsc_ordered() into a generic barrier primitive, barrier_nospec().
One of the mitigations for Spectre variant1 vulnerabilities is to fence
speculative execution after successfully validating a bounds check. I.e.
force the result of a bounds check to resolve in the instruction pipeline
to ensure speculative execution honors that result before potentially
operating on out-of-bounds data.
No functional changes.
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Suggested-by: Andi Kleen <ak(a)linux.intel.com>
Suggested-by: Ingo Molnar <mingo(a)redhat.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: Tom Lendacky <thomas.lendacky(a)amd.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727415361.33451.9049453007262764675.stgit@dwil…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/barrier.h | 4 ++++
arch/x86/include/asm/msr.h | 3 +--
2 files changed, 5 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -47,6 +47,10 @@ static inline unsigned long array_index_
/* Override the default implementation from linux/nospec.h. */
#define array_index_mask_nospec array_index_mask_nospec
+/* Prevent speculative execution past this barrier. */
+#define barrier_nospec() alternative_2("", "mfence", X86_FEATURE_MFENCE_RDTSC, \
+ "lfence", X86_FEATURE_LFENCE_RDTSC)
+
#ifdef CONFIG_X86_PPRO_FENCE
#define dma_rmb() rmb()
#else
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -188,8 +188,7 @@ static __always_inline unsigned long lon
* that some other imaginary CPU is updating continuously with a
* time stamp.
*/
- alternative_2("", "mfence", X86_FEATURE_MFENCE_RDTSC,
- "lfence", X86_FEATURE_LFENCE_RDTSC);
+ barrier_nospec();
return rdtsc();
}
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:02:39 -0800
Subject: x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd)
For __get_user() paths, do not allow the kernel to speculate on the value
of a user controlled pointer. In addition to the 'stac' instruction for
Supervisor Mode Access Protection (SMAP), a barrier_nospec() causes the
access_ok() result to resolve in the pipeline before the CPU might take any
speculative action on the pointer value. Given the cost of 'stac' the
speculation barrier is placed after 'stac' to hopefully overlap the cost of
disabling SMAP with the cost of flushing the instruction pipeline.
Since __get_user is a major kernel interface that deals with user
controlled pointers, the __uaccess_begin_nospec() mechanism will prevent
speculative execution past an access_ok() permission check. While
speculative execution past access_ok() is not enough to lead to a kernel
memory leak, it is a necessary precondition.
To be clear, __uaccess_begin_nospec() is addressing a class of potential
problems near __get_user() usages.
Note, that while the barrier_nospec() in __uaccess_begin_nospec() is used
to protect __get_user(), pointer masking similar to array_index_nospec()
will be used for get_user() since it incorporates a bounds check near the
usage.
uaccess_try_nospec provides the same mechanism for get_user_try.
No functional changes.
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Suggested-by: Andi Kleen <ak(a)linux.intel.com>
Suggested-by: Ingo Molnar <mingo(a)redhat.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: Tom Lendacky <thomas.lendacky(a)amd.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727415922.33451.5796614273104346583.stgit@dwil…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/uaccess.h | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -123,6 +123,11 @@ extern int __get_user_bad(void);
#define __uaccess_begin() stac()
#define __uaccess_end() clac()
+#define __uaccess_begin_nospec() \
+({ \
+ stac(); \
+ barrier_nospec(); \
+})
/*
* This is a type: either unsigned long, if the argument fits into
@@ -474,6 +479,10 @@ struct __large_struct { unsigned long bu
__uaccess_begin(); \
barrier();
+#define uaccess_try_nospec do { \
+ current->thread.uaccess_err = 0; \
+ __uaccess_begin_nospec(); \
+
#define uaccess_catch(err) \
__uaccess_end(); \
(err) |= (current->thread.uaccess_err ? -EFAULT : 0); \
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86: Implement array_index_mask_nospec
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-implement-array_index_mask_nospec.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:02:28 -0800
Subject: x86: Implement array_index_mask_nospec
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit babdde2698d482b6c0de1eab4f697cf5856c5859)
array_index_nospec() uses a mask to sanitize user controllable array
indexes, i.e. generate a 0 mask if 'index' >= 'size', and a ~0 mask
otherwise. While the default array_index_mask_nospec() handles the
carry-bit from the (index - size) result in software.
The x86 array_index_mask_nospec() does the same, but the carry-bit is
handled in the processor CF flag without conditional instructions in the
control flow.
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727414808.33451.1873237130672785331.stgit@dwil…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/barrier.h | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -23,6 +23,30 @@
#define wmb() asm volatile("sfence" ::: "memory")
#endif
+/**
+ * array_index_mask_nospec() - generate a mask that is ~0UL when the
+ * bounds check succeeds and 0 otherwise
+ * @index: array element index
+ * @size: number of elements in array
+ *
+ * Returns:
+ * 0 - (index < size)
+ */
+static inline unsigned long array_index_mask_nospec(unsigned long index,
+ unsigned long size)
+{
+ unsigned long mask;
+
+ asm ("cmp %1,%2; sbb %0,%0;"
+ :"=r" (mask)
+ :"r"(size),"r" (index)
+ :"cc");
+ return mask;
+}
+
+/* Override the default implementation from linux/nospec.h. */
+#define array_index_mask_nospec array_index_mask_nospec
+
#ifdef CONFIG_X86_PPRO_FENCE
#define dma_rmb() rmb()
#else
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86/get_user: Use pointer masking to limit speculation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-get_user-use-pointer-masking-to-limit-speculation.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:02:54 -0800
Subject: x86/get_user: Use pointer masking to limit speculation
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit c7f631cb07e7da06ac1d231ca178452339e32a94)
Quoting Linus:
I do think that it would be a good idea to very expressly document
the fact that it's not that the user access itself is unsafe. I do
agree that things like "get_user()" want to be protected, but not
because of any direct bugs or problems with get_user() and friends,
but simply because get_user() is an excellent source of a pointer
that is obviously controlled from a potentially attacking user
space. So it's a prime candidate for then finding _subsequent_
accesses that can then be used to perturb the cache.
Unlike the __get_user() case get_user() includes the address limit check
near the pointer de-reference. With that locality the speculation can be
mitigated with pointer narrowing rather than a barrier, i.e.
array_index_nospec(). Where the narrowing is performed by:
cmp %limit, %ptr
sbb %mask, %mask
and %mask, %ptr
With respect to speculation the value of %ptr is either less than %limit
or NULL.
Co-developed-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: Kees Cook <keescook(a)chromium.org>
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: torvalds(a)linux-foundation.org
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727417469.33451.11804043010080838495.stgit@dwi…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/lib/getuser.S | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/arch/x86/lib/getuser.S
+++ b/arch/x86/lib/getuser.S
@@ -39,6 +39,8 @@ ENTRY(__get_user_1)
mov PER_CPU_VAR(current_task), %_ASM_DX
cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user
+ sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
+ and %_ASM_DX, %_ASM_AX
ASM_STAC
1: movzbl (%_ASM_AX),%edx
xor %eax,%eax
@@ -53,6 +55,8 @@ ENTRY(__get_user_2)
mov PER_CPU_VAR(current_task), %_ASM_DX
cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user
+ sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
+ and %_ASM_DX, %_ASM_AX
ASM_STAC
2: movzwl -1(%_ASM_AX),%edx
xor %eax,%eax
@@ -67,6 +71,8 @@ ENTRY(__get_user_4)
mov PER_CPU_VAR(current_task), %_ASM_DX
cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user
+ sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
+ and %_ASM_DX, %_ASM_AX
ASM_STAC
3: movl -3(%_ASM_AX),%edx
xor %eax,%eax
@@ -82,6 +88,8 @@ ENTRY(__get_user_8)
mov PER_CPU_VAR(current_task), %_ASM_DX
cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user
+ sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
+ and %_ASM_DX, %_ASM_AX
ASM_STAC
4: movq -7(%_ASM_AX),%rdx
xor %eax,%eax
@@ -93,6 +101,8 @@ ENTRY(__get_user_8)
mov PER_CPU_VAR(current_task), %_ASM_DX
cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user_8
+ sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
+ and %_ASM_DX, %_ASM_AX
ASM_STAC
4: movl -7(%_ASM_AX),%edx
5: movl -3(%_ASM_AX),%ecx
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86/entry/64: Remove the SYSCALL64 fast path
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-entry-64-remove-the-syscall64-fast-path.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 8 03:30:27 CET 2018
From: Andy Lutomirski <luto(a)kernel.org>
Date: Sun, 28 Jan 2018 10:38:49 -0800
Subject: x86/entry/64: Remove the SYSCALL64 fast path
From: Andy Lutomirski <luto(a)kernel.org>
(cherry picked from commit 21d375b6b34ff511a507de27bf316b3dde6938d9)
The SYCALLL64 fast path was a nice, if small, optimization back in the good
old days when syscalls were actually reasonably fast. Now there is PTI to
slow everything down, and indirect branches are verboten, making everything
messier. The retpoline code in the fast path is particularly nasty.
Just get rid of the fast path. The slow path is barely slower.
[ tglx: Split out the 'push all extra regs' part ]
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Kernel Hardening <kernel-hardening(a)lists.openwall.com>
Link: https://lkml.kernel.org/r/462dff8d4d64dfbfc851fbf3130641809d980ecd.15171644…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/entry/entry_64.S | 123 --------------------------------------------
arch/x86/entry/syscall_64.c | 7 --
2 files changed, 3 insertions(+), 127 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -179,94 +179,11 @@ GLOBAL(entry_SYSCALL_64_after_swapgs)
pushq %r11 /* pt_regs->r11 */
sub $(6*8), %rsp /* pt_regs->bp, bx, r12-15 not saved */
- /*
- * If we need to do entry work or if we guess we'll need to do
- * exit work, go straight to the slow path.
- */
- movq PER_CPU_VAR(current_task), %r11
- testl $_TIF_WORK_SYSCALL_ENTRY|_TIF_ALLWORK_MASK, TASK_TI_flags(%r11)
- jnz entry_SYSCALL64_slow_path
-
-entry_SYSCALL_64_fastpath:
- /*
- * Easy case: enable interrupts and issue the syscall. If the syscall
- * needs pt_regs, we'll call a stub that disables interrupts again
- * and jumps to the slow path.
- */
- TRACE_IRQS_ON
- ENABLE_INTERRUPTS(CLBR_NONE)
-#if __SYSCALL_MASK == ~0
- cmpq $__NR_syscall_max, %rax
-#else
- andl $__SYSCALL_MASK, %eax
- cmpl $__NR_syscall_max, %eax
-#endif
- ja 1f /* return -ENOSYS (already in pt_regs->ax) */
- movq %r10, %rcx
-
- /*
- * This call instruction is handled specially in stub_ptregs_64.
- * It might end up jumping to the slow path. If it jumps, RAX
- * and all argument registers are clobbered.
- */
-#ifdef CONFIG_RETPOLINE
- movq sys_call_table(, %rax, 8), %rax
- call __x86_indirect_thunk_rax
-#else
- call *sys_call_table(, %rax, 8)
-#endif
-.Lentry_SYSCALL_64_after_fastpath_call:
-
- movq %rax, RAX(%rsp)
-1:
-
- /*
- * If we get here, then we know that pt_regs is clean for SYSRET64.
- * If we see that no exit work is required (which we are required
- * to check with IRQs off), then we can go straight to SYSRET64.
- */
- DISABLE_INTERRUPTS(CLBR_NONE)
- TRACE_IRQS_OFF
- movq PER_CPU_VAR(current_task), %r11
- testl $_TIF_ALLWORK_MASK, TASK_TI_flags(%r11)
- jnz 1f
-
- LOCKDEP_SYS_EXIT
- TRACE_IRQS_ON /* user mode is traced as IRQs on */
- movq RIP(%rsp), %rcx
- movq EFLAGS(%rsp), %r11
- RESTORE_C_REGS_EXCEPT_RCX_R11
- /*
- * This opens a window where we have a user CR3, but are
- * running in the kernel. This makes using the CS
- * register useless for telling whether or not we need to
- * switch CR3 in NMIs. Normal interrupts are OK because
- * they are off here.
- */
- SWITCH_USER_CR3
- movq RSP(%rsp), %rsp
- USERGS_SYSRET64
-
-1:
- /*
- * The fast path looked good when we started, but something changed
- * along the way and we need to switch to the slow path. Calling
- * raise(3) will trigger this, for example. IRQs are off.
- */
- TRACE_IRQS_ON
- ENABLE_INTERRUPTS(CLBR_NONE)
- SAVE_EXTRA_REGS
- movq %rsp, %rdi
- call syscall_return_slowpath /* returns with IRQs disabled */
- jmp return_from_SYSCALL_64
-
-entry_SYSCALL64_slow_path:
/* IRQs are off. */
SAVE_EXTRA_REGS
movq %rsp, %rdi
call do_syscall_64 /* returns with IRQs disabled */
-return_from_SYSCALL_64:
RESTORE_EXTRA_REGS
TRACE_IRQS_IRETQ /* we're about to change IF */
@@ -339,6 +256,7 @@ return_from_SYSCALL_64:
syscall_return_via_sysret:
/* rcx and r11 are already restored (see code above) */
RESTORE_C_REGS_EXCEPT_RCX_R11
+
/*
* This opens a window where we have a user CR3, but are
* running in the kernel. This makes using the CS
@@ -363,45 +281,6 @@ opportunistic_sysret_failed:
jmp restore_c_regs_and_iret
END(entry_SYSCALL_64)
-ENTRY(stub_ptregs_64)
- /*
- * Syscalls marked as needing ptregs land here.
- * If we are on the fast path, we need to save the extra regs,
- * which we achieve by trying again on the slow path. If we are on
- * the slow path, the extra regs are already saved.
- *
- * RAX stores a pointer to the C function implementing the syscall.
- * IRQs are on.
- */
- cmpq $.Lentry_SYSCALL_64_after_fastpath_call, (%rsp)
- jne 1f
-
- /*
- * Called from fast path -- disable IRQs again, pop return address
- * and jump to slow path
- */
- DISABLE_INTERRUPTS(CLBR_NONE)
- TRACE_IRQS_OFF
- popq %rax
- jmp entry_SYSCALL64_slow_path
-
-1:
- JMP_NOSPEC %rax /* Called from C */
-END(stub_ptregs_64)
-
-.macro ptregs_stub func
-ENTRY(ptregs_\func)
- leaq \func(%rip), %rax
- jmp stub_ptregs_64
-END(ptregs_\func)
-.endm
-
-/* Instantiate ptregs_stub for each ptregs-using syscall */
-#define __SYSCALL_64_QUAL_(sym)
-#define __SYSCALL_64_QUAL_ptregs(sym) ptregs_stub sym
-#define __SYSCALL_64(nr, sym, qual) __SYSCALL_64_QUAL_##qual(sym)
-#include <asm/syscalls_64.h>
-
/*
* %rdi: prev task
* %rsi: next task
--- a/arch/x86/entry/syscall_64.c
+++ b/arch/x86/entry/syscall_64.c
@@ -6,14 +6,11 @@
#include <asm/asm-offsets.h>
#include <asm/syscall.h>
-#define __SYSCALL_64_QUAL_(sym) sym
-#define __SYSCALL_64_QUAL_ptregs(sym) ptregs_##sym
-
-#define __SYSCALL_64(nr, sym, qual) extern asmlinkage long __SYSCALL_64_QUAL_##qual(sym)(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long);
+#define __SYSCALL_64(nr, sym, qual) extern asmlinkage long sym(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long);
#include <asm/syscalls_64.h>
#undef __SYSCALL_64
-#define __SYSCALL_64(nr, sym, qual) [nr] = __SYSCALL_64_QUAL_##qual(sym),
+#define __SYSCALL_64(nr, sym, qual) [nr] = sym,
extern long sys_ni_syscall(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long);
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.9/x86-entry-64-push-extra-regs-right-away.patch
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/x86-asm-move-status-from-thread_struct-to-thread_info.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-entry-64-remove-the-syscall64-fast-path.patch
queue-4.9/x86-asm-fix-inline-asm-call-constraints-for-gcc-4.4.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/x86-pti-mark-constant-arrays-as-__initconst.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
This is a note to let you know that I've just added the patch titled
x86/entry/64: Push extra regs right away
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-entry-64-push-extra-regs-right-away.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 Thu Feb 8 03:30:27 CET 2018
From: Andy Lutomirski <luto(a)kernel.org>
Date: Sun, 28 Jan 2018 10:38:49 -0800
Subject: x86/entry/64: Push extra regs right away
From: Andy Lutomirski <luto(a)kernel.org>
(cherry picked from commit d1f7732009e0549eedf8ea1db948dc37be77fd46)
With the fast path removed there is no point in splitting the push of the
normal and the extra register set. Just push the extra regs right away.
[ tglx: Split out from 'x86/entry/64: Remove the SYSCALL64 fast path' ]
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Kernel Hardening <kernel-hardening(a)lists.openwall.com>
Link: https://lkml.kernel.org/r/462dff8d4d64dfbfc851fbf3130641809d980ecd.15171644…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/entry/entry_64.S | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -177,10 +177,14 @@ GLOBAL(entry_SYSCALL_64_after_swapgs)
pushq %r9 /* pt_regs->r9 */
pushq %r10 /* pt_regs->r10 */
pushq %r11 /* pt_regs->r11 */
- sub $(6*8), %rsp /* pt_regs->bp, bx, r12-15 not saved */
+ pushq %rbx /* pt_regs->rbx */
+ pushq %rbp /* pt_regs->rbp */
+ pushq %r12 /* pt_regs->r12 */
+ pushq %r13 /* pt_regs->r13 */
+ pushq %r14 /* pt_regs->r14 */
+ pushq %r15 /* pt_regs->r15 */
/* IRQs are off. */
- SAVE_EXTRA_REGS
movq %rsp, %rdi
call do_syscall_64 /* returns with IRQs disabled */
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.9/x86-entry-64-push-extra-regs-right-away.patch
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/x86-asm-move-status-from-thread_struct-to-thread_info.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-entry-64-remove-the-syscall64-fast-path.patch
queue-4.9/x86-asm-fix-inline-asm-call-constraints-for-gcc-4.4.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/x86-pti-mark-constant-arrays-as-__initconst.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
This is a note to let you know that I've just added the patch titled
x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-cpuid-fix-up-virtual-ibrs-ibpb-stibp-feature-bits-on-intel.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 Thu Feb 8 03:32:24 CET 2018
From: David Woodhouse <dwmw(a)amazon.co.uk>
Date: Tue, 30 Jan 2018 14:30:23 +0000
Subject: x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel
From: David Woodhouse <dwmw(a)amazon.co.uk>
(cherry picked from commit 7fcae1118f5fd44a862aa5c3525248e35ee67c3b)
Despite the fact that all the other code there seems to be doing it, just
using set_cpu_cap() in early_intel_init() doesn't actually work.
For CPUs with PKU support, setup_pku() calls get_cpu_cap() after
c->c_init() has set those feature bits. That resets those bits back to what
was queried from the hardware.
Turning the bits off for bad microcode is easy to fix. That can just use
setup_clear_cpu_cap() to force them off for all CPUs.
I was less keen on forcing the feature bits *on* that way, just in case
of inconsistencies. I appreciate that the kernel is going to get this
utterly wrong if CPU features are not consistent, because it has already
applied alternatives by the time secondary CPUs are brought up.
But at least if setup_force_cpu_cap() isn't being used, we might have a
chance of *detecting* the lack of the corresponding bit and either
panicking or refusing to bring the offending CPU online.
So ensure that the appropriate feature bits are set within get_cpu_cap()
regardless of how many extra times it's called.
Fixes: 2961298e ("x86/cpufeatures: Clean up Spectre v2 related CPUID flags")
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: karahmed(a)amazon.de
Cc: peterz(a)infradead.org
Cc: bp(a)alien8.de
Link: https://lkml.kernel.org/r/1517322623-15261-1-git-send-email-dwmw@amazon.co.…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/common.c | 21 +++++++++++++++++++++
arch/x86/kernel/cpu/intel.c | 27 ++++++++-------------------
2 files changed, 29 insertions(+), 19 deletions(-)
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -718,6 +718,26 @@ static void apply_forced_caps(struct cpu
}
}
+static void init_speculation_control(struct cpuinfo_x86 *c)
+{
+ /*
+ * The Intel SPEC_CTRL CPUID bit implies IBRS and IBPB support,
+ * and they also have a different bit for STIBP support. Also,
+ * a hypervisor might have set the individual AMD bits even on
+ * Intel CPUs, for finer-grained selection of what's available.
+ *
+ * We use the AMD bits in 0x8000_0008 EBX as the generic hardware
+ * features, which are visible in /proc/cpuinfo and used by the
+ * kernel. So set those accordingly from the Intel bits.
+ */
+ if (cpu_has(c, X86_FEATURE_SPEC_CTRL)) {
+ set_cpu_cap(c, X86_FEATURE_IBRS);
+ set_cpu_cap(c, X86_FEATURE_IBPB);
+ }
+ if (cpu_has(c, X86_FEATURE_INTEL_STIBP))
+ set_cpu_cap(c, X86_FEATURE_STIBP);
+}
+
void get_cpu_cap(struct cpuinfo_x86 *c)
{
u32 eax, ebx, ecx, edx;
@@ -812,6 +832,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
c->x86_capability[CPUID_8000_000A_EDX] = cpuid_edx(0x8000000a);
init_scattered_cpuid_features(c);
+ init_speculation_control(c);
}
static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c)
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -140,28 +140,17 @@ static void early_init_intel(struct cpui
rdmsr(MSR_IA32_UCODE_REV, lower_word, c->microcode);
}
- /*
- * The Intel SPEC_CTRL CPUID bit implies IBRS and IBPB support,
- * and they also have a different bit for STIBP support. Also,
- * a hypervisor might have set the individual AMD bits even on
- * Intel CPUs, for finer-grained selection of what's available.
- */
- if (cpu_has(c, X86_FEATURE_SPEC_CTRL)) {
- set_cpu_cap(c, X86_FEATURE_IBRS);
- set_cpu_cap(c, X86_FEATURE_IBPB);
- }
- if (cpu_has(c, X86_FEATURE_INTEL_STIBP))
- set_cpu_cap(c, X86_FEATURE_STIBP);
-
/* Now if any of them are set, check the blacklist and clear the lot */
- if ((cpu_has(c, X86_FEATURE_IBRS) || cpu_has(c, X86_FEATURE_IBPB) ||
+ if ((cpu_has(c, X86_FEATURE_SPEC_CTRL) ||
+ cpu_has(c, X86_FEATURE_INTEL_STIBP) ||
+ cpu_has(c, X86_FEATURE_IBRS) || cpu_has(c, X86_FEATURE_IBPB) ||
cpu_has(c, X86_FEATURE_STIBP)) && bad_spectre_microcode(c)) {
pr_warn("Intel Spectre v2 broken microcode detected; disabling Speculation Control\n");
- clear_cpu_cap(c, X86_FEATURE_IBRS);
- clear_cpu_cap(c, X86_FEATURE_IBPB);
- clear_cpu_cap(c, X86_FEATURE_STIBP);
- clear_cpu_cap(c, X86_FEATURE_SPEC_CTRL);
- clear_cpu_cap(c, X86_FEATURE_INTEL_STIBP);
+ setup_clear_cpu_cap(X86_FEATURE_IBRS);
+ setup_clear_cpu_cap(X86_FEATURE_IBPB);
+ setup_clear_cpu_cap(X86_FEATURE_STIBP);
+ setup_clear_cpu_cap(X86_FEATURE_SPEC_CTRL);
+ setup_clear_cpu_cap(X86_FEATURE_INTEL_STIBP);
}
/*
Patches currently in stable-queue which might be from dwmw(a)amazon.co.uk are
queue-4.9/x86-entry-64-push-extra-regs-right-away.patch
queue-4.9/kvm-vmx-introduce-alloc_loaded_vmcs.patch
queue-4.9/kvm-nvmx-eliminate-vmcs02-pool.patch
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-retpoline-simplify-vmexit_fill_rsb.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/x86-cpufeatures-clean-up-spectre-v2-related-cpuid-flags.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/x86-asm-move-status-from-thread_struct-to-thread_info.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-entry-64-remove-the-syscall64-fast-path.patch
queue-4.9/x86-cpufeature-blacklist-spec_ctrl-pred_cmd-on-early-spectre-v2-microcodes.patch
queue-4.9/x86-nospec-fix-header-guards-names.patch
queue-4.9/x86-retpoline-avoid-retpolines-for-built-in-__init-functions.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-cpu-bugs-make-retpoline-module-warning-conditional.patch
queue-4.9/x86-spectre-check-config_retpoline-in-command-line-parser.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/x86-alternative-print-unadorned-pointers.patch
queue-4.9/x86-cpuid-fix-up-virtual-ibrs-ibpb-stibp-feature-bits-on-intel.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
queue-4.9/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.9/module-retpoline-warn-about-missing-retpoline-in-module.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/kvm-nvmx-vmx_complete_nested_posted_interrupt-can-t-fail.patch
queue-4.9/x86-spectre-simplify-spectre_v2-command-line-parsing.patch
queue-4.9/x86-msr-add-definitions-for-new-speculation-control-msrs.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/kvm-vmx-make-msr-bitmaps-per-vcpu.patch
queue-4.9/x86-speculation-add-basic-ibpb-indirect-branch-prediction-barrier-support.patch
queue-4.9/kvm-nvmx-mark-vmcs12-pages-dirty-on-l2-exit.patch
queue-4.9/x86-pti-mark-constant-arrays-as-__initconst.patch
queue-4.9/x86-speculation-fix-typo-ibrs_att-which-should-be-ibrs_all.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-bugs-drop-one-mitigation-from-dmesg.patch
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
x86/asm: Move 'status' from thread_struct to thread_info
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-asm-move-status-from-thread_struct-to-thread_info.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 Thu Feb 8 03:32:24 CET 2018
From: Andy Lutomirski <luto(a)kernel.org>
Date: Sun, 28 Jan 2018 10:38:50 -0800
Subject: x86/asm: Move 'status' from thread_struct to thread_info
From: Andy Lutomirski <luto(a)kernel.org>
(cherry picked from commit 37a8f7c38339b22b69876d6f5a0ab851565284e3)
The TS_COMPAT bit is very hot and is accessed from code paths that mostly
also touch thread_info::flags. Move it into struct thread_info to improve
cache locality.
The only reason it was in thread_struct is that there was a brief period
during which arch-specific fields were not allowed in struct thread_info.
Linus suggested further changing:
ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED);
to:
if (unlikely(ti->status & (TS_COMPAT|TS_I386_REGS_POKED)))
ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED);
on the theory that frequently dirtying the cacheline even in pure 64-bit
code that never needs to modify status hurts performance. That could be a
reasonable followup patch, but I suspect it matters less on top of this
patch.
Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Ingo Molnar <mingo(a)kernel.org>
Acked-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Kernel Hardening <kernel-hardening(a)lists.openwall.com>
Link: https://lkml.kernel.org/r/03148bcc1b217100e6e8ecf6a5468c45cf4304b6.15171644…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/entry/common.c | 4 ++--
arch/x86/include/asm/processor.h | 2 --
arch/x86/include/asm/syscall.h | 6 +++---
arch/x86/include/asm/thread_info.h | 3 ++-
arch/x86/kernel/process_64.c | 4 ++--
arch/x86/kernel/ptrace.c | 2 +-
arch/x86/kernel/signal.c | 2 +-
7 files changed, 11 insertions(+), 12 deletions(-)
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -201,7 +201,7 @@ __visible inline void prepare_exit_to_us
* special case only applies after poking regs and before the
* very next return to user mode.
*/
- current->thread.status &= ~(TS_COMPAT|TS_I386_REGS_POKED);
+ ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED);
#endif
user_enter_irqoff();
@@ -299,7 +299,7 @@ static __always_inline void do_syscall_3
unsigned int nr = (unsigned int)regs->orig_ax;
#ifdef CONFIG_IA32_EMULATION
- current->thread.status |= TS_COMPAT;
+ ti->status |= TS_COMPAT;
#endif
if (READ_ONCE(ti->flags) & _TIF_WORK_SYSCALL_ENTRY) {
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -391,8 +391,6 @@ struct thread_struct {
unsigned short gsindex;
#endif
- u32 status; /* thread synchronous flags */
-
#ifdef CONFIG_X86_64
unsigned long fsbase;
unsigned long gsbase;
--- a/arch/x86/include/asm/syscall.h
+++ b/arch/x86/include/asm/syscall.h
@@ -60,7 +60,7 @@ static inline long syscall_get_error(str
* TS_COMPAT is set for 32-bit syscall entries and then
* remains set until we return to user mode.
*/
- if (task->thread.status & (TS_COMPAT|TS_I386_REGS_POKED))
+ if (task->thread_info.status & (TS_COMPAT|TS_I386_REGS_POKED))
/*
* Sign-extend the value so (int)-EFOO becomes (long)-EFOO
* and will match correctly in comparisons.
@@ -116,7 +116,7 @@ static inline void syscall_get_arguments
unsigned long *args)
{
# ifdef CONFIG_IA32_EMULATION
- if (task->thread.status & TS_COMPAT)
+ if (task->thread_info.status & TS_COMPAT)
switch (i) {
case 0:
if (!n--) break;
@@ -177,7 +177,7 @@ static inline void syscall_set_arguments
const unsigned long *args)
{
# ifdef CONFIG_IA32_EMULATION
- if (task->thread.status & TS_COMPAT)
+ if (task->thread_info.status & TS_COMPAT)
switch (i) {
case 0:
if (!n--) break;
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -54,6 +54,7 @@ struct task_struct;
struct thread_info {
unsigned long flags; /* low level flags */
+ u32 status; /* thread synchronous flags */
};
#define INIT_THREAD_INFO(tsk) \
@@ -213,7 +214,7 @@ static inline int arch_within_stack_fram
#define in_ia32_syscall() true
#else
#define in_ia32_syscall() (IS_ENABLED(CONFIG_IA32_EMULATION) && \
- current->thread.status & TS_COMPAT)
+ current_thread_info()->status & TS_COMPAT)
#endif
/*
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -538,7 +538,7 @@ void set_personality_ia32(bool x32)
current->personality &= ~READ_IMPLIES_EXEC;
/* in_compat_syscall() uses the presence of the x32
syscall bit flag to determine compat status */
- current->thread.status &= ~TS_COMPAT;
+ current_thread_info()->status &= ~TS_COMPAT;
} else {
set_thread_flag(TIF_IA32);
clear_thread_flag(TIF_X32);
@@ -546,7 +546,7 @@ void set_personality_ia32(bool x32)
current->mm->context.ia32_compat = TIF_IA32;
current->personality |= force_personality32;
/* Prepare the first "return" to user space */
- current->thread.status |= TS_COMPAT;
+ current_thread_info()->status |= TS_COMPAT;
}
}
EXPORT_SYMBOL_GPL(set_personality_ia32);
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -934,7 +934,7 @@ static int putreg32(struct task_struct *
*/
regs->orig_ax = value;
if (syscall_get_nr(child, regs) >= 0)
- child->thread.status |= TS_I386_REGS_POKED;
+ child->thread_info.status |= TS_I386_REGS_POKED;
break;
case offsetof(struct user32, regs.eflags):
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -785,7 +785,7 @@ static inline unsigned long get_nr_resta
* than the tracee.
*/
#ifdef CONFIG_IA32_EMULATION
- if (current->thread.status & (TS_COMPAT|TS_I386_REGS_POKED))
+ if (current_thread_info()->status & (TS_COMPAT|TS_I386_REGS_POKED))
return __NR_ia32_restart_syscall;
#endif
#ifdef CONFIG_X86_X32_ABI
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.9/x86-entry-64-push-extra-regs-right-away.patch
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/x86-asm-move-status-from-thread_struct-to-thread_info.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-entry-64-remove-the-syscall64-fast-path.patch
queue-4.9/x86-asm-fix-inline-asm-call-constraints-for-gcc-4.4.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/x86-pti-mark-constant-arrays-as-__initconst.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
This is a note to let you know that I've just added the patch titled
x86/bugs: Drop one "mitigation" from dmesg
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-bugs-drop-one-mitigation-from-dmesg.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 Thu Feb 8 03:30:27 CET 2018
From: Borislav Petkov <bp(a)suse.de>
Date: Fri, 26 Jan 2018 13:11:39 +0100
Subject: x86/bugs: Drop one "mitigation" from dmesg
From: Borislav Petkov <bp(a)suse.de>
(cherry picked from commit 55fa19d3e51f33d9cd4056d25836d93abf9438db)
Make
[ 0.031118] Spectre V2 mitigation: Mitigation: Full generic retpoline
into
[ 0.031118] Spectre V2: Mitigation: Full generic retpoline
to reduce the mitigation mitigations strings.
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: riel(a)redhat.com
Cc: ak(a)linux.intel.com
Cc: peterz(a)infradead.org
Cc: David Woodhouse <dwmw2(a)infradead.org>
Cc: jikos(a)kernel.org
Cc: luto(a)amacapital.net
Cc: dave.hansen(a)intel.com
Cc: torvalds(a)linux-foundation.org
Cc: keescook(a)google.com
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: tim.c.chen(a)linux.intel.com
Cc: pjt(a)google.com
Link: https://lkml.kernel.org/r/20180126121139.31959-5-bp@alien8.de
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/bugs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -90,7 +90,7 @@ static const char *spectre_v2_strings[]
};
#undef pr_fmt
-#define pr_fmt(fmt) "Spectre V2 mitigation: " fmt
+#define pr_fmt(fmt) "Spectre V2 : " fmt
static enum spectre_v2_mitigation spectre_v2_enabled = SPECTRE_V2_NONE;
static bool spectre_v2_bad_module;
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-retpoline-simplify-vmexit_fill_rsb.patch
queue-4.9/x86-cpufeatures-clean-up-spectre-v2-related-cpuid-flags.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch
queue-4.9/x86-nospec-fix-header-guards-names.patch
queue-4.9/x86-alternative-print-unadorned-pointers.patch
queue-4.9/x86-spectre-fix-spelling-mistake-vunerable-vulnerable.patch
queue-4.9/x86-pti-mark-constant-arrays-as-__initconst.patch
queue-4.9/x86-bugs-drop-one-mitigation-from-dmesg.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
This is a note to let you know that I've just added the patch titled
nl80211: Sanitize array index in parse_txq_params
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:
nl80211-sanitize-array-index-in-parse_txq_params.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:03:15 -0800
Subject: nl80211: Sanitize array index in parse_txq_params
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit 259d8c1e984318497c84eef547bbb6b1d9f4eb05)
Wireless drivers rely on parse_txq_params to validate that txq_params->ac
is less than NL80211_NUM_ACS by the time the low-level driver's ->conf_tx()
handler is called. Use a new helper, array_index_nospec(), to sanitize
txq_params->ac with respect to speculation. I.e. ensure that any
speculation into ->conf_tx() handlers is done with a value of
txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS).
Reported-by: Christian Lamparter <chunkeey(a)gmail.com>
Reported-by: Elena Reshetova <elena.reshetova(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Johannes Berg <johannes(a)sipsolutions.net>
Cc: linux-arch(a)vger.kernel.org
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: linux-wireless(a)vger.kernel.org
Cc: torvalds(a)linux-foundation.org
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727419584.33451.7700736761686184303.stgit@dwil…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/wireless/nl80211.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -16,6 +16,7 @@
#include <linux/nl80211.h>
#include <linux/rtnetlink.h>
#include <linux/netlink.h>
+#include <linux/nospec.h>
#include <linux/etherdevice.h>
#include <net/net_namespace.h>
#include <net/genetlink.h>
@@ -2014,20 +2015,22 @@ static const struct nla_policy txq_param
static int parse_txq_params(struct nlattr *tb[],
struct ieee80211_txq_params *txq_params)
{
+ u8 ac;
+
if (!tb[NL80211_TXQ_ATTR_AC] || !tb[NL80211_TXQ_ATTR_TXOP] ||
!tb[NL80211_TXQ_ATTR_CWMIN] || !tb[NL80211_TXQ_ATTR_CWMAX] ||
!tb[NL80211_TXQ_ATTR_AIFS])
return -EINVAL;
- txq_params->ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
+ ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
txq_params->txop = nla_get_u16(tb[NL80211_TXQ_ATTR_TXOP]);
txq_params->cwmin = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMIN]);
txq_params->cwmax = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMAX]);
txq_params->aifs = nla_get_u8(tb[NL80211_TXQ_ATTR_AIFS]);
- if (txq_params->ac >= NL80211_NUM_ACS)
+ if (ac >= NL80211_NUM_ACS)
return -EINVAL;
-
+ txq_params->ac = array_index_nospec(ac, NL80211_NUM_ACS);
return 0;
}
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
vfs, fdtable: Prevent bounds-check bypass via speculative execution
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:
vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:03:05 -0800
Subject: vfs, fdtable: Prevent bounds-check bypass via speculative execution
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit 56c30ba7b348b90484969054d561f711ba196507)
'fd' is a user controlled value that is used as a data dependency to
read from the 'fdt->fd' array. In order to avoid potential leaks of
kernel memory values, block speculative execution of the instruction
stream that could issue reads based on an invalid 'file *' returned from
__fcheck_files.
Co-developed-by: Elena Reshetova <elena.reshetova(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: kernel-hardening(a)lists.openwall.com
Cc: gregkh(a)linuxfoundation.org
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: torvalds(a)linux-foundation.org
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727418500.33451.17392199002892248656.stgit@dwi…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/fdtable.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/include/linux/fdtable.h
+++ b/include/linux/fdtable.h
@@ -9,6 +9,7 @@
#include <linux/compiler.h>
#include <linux/spinlock.h>
#include <linux/rcupdate.h>
+#include <linux/nospec.h>
#include <linux/types.h>
#include <linux/init.h>
#include <linux/fs.h>
@@ -81,8 +82,10 @@ static inline struct file *__fcheck_file
{
struct fdtable *fdt = rcu_dereference_raw(files->fdt);
- if (fd < fdt->max_fds)
+ if (fd < fdt->max_fds) {
+ fd = array_index_nospec(fd, fdt->max_fds);
return rcu_dereference_raw(fdt->fd[fd]);
+ }
return NULL;
}
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
array_index_nospec: Sanitize speculative array de-references
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:
array_index_nospec-sanitize-speculative-array-de-references.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 Thu Feb 8 03:32:24 CET 2018
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon, 29 Jan 2018 17:02:22 -0800
Subject: array_index_nospec: Sanitize speculative array de-references
From: Dan Williams <dan.j.williams(a)intel.com>
(cherry picked from commit f3804203306e098dae9ca51540fcd5eb700d7f40)
array_index_nospec() is proposed as a generic mechanism to mitigate
against Spectre-variant-1 attacks, i.e. an attack that bypasses boundary
checks via speculative execution. The array_index_nospec()
implementation is expected to be safe for current generation CPUs across
multiple architectures (ARM, x86).
Based on an original implementation by Linus Torvalds, tweaked to remove
speculative flows by Alexei Starovoitov, and tweaked again by Linus to
introduce an x86 assembly implementation for the mask generation.
Co-developed-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Co-developed-by: Alexei Starovoitov <ast(a)kernel.org>
Suggested-by: Cyril Novikov <cnovikov(a)lynx.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: kernel-hardening(a)lists.openwall.com
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: Russell King <linux(a)armlinux.org.uk>
Cc: gregkh(a)linuxfoundation.org
Cc: torvalds(a)linux-foundation.org
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727414229.33451.18411580953862676575.stgit@dwi…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/nospec.h | 72 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
create mode 100644 include/linux/nospec.h
--- /dev/null
+++ b/include/linux/nospec.h
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright(c) 2018 Linus Torvalds. All rights reserved.
+// Copyright(c) 2018 Alexei Starovoitov. All rights reserved.
+// Copyright(c) 2018 Intel Corporation. All rights reserved.
+
+#ifndef _LINUX_NOSPEC_H
+#define _LINUX_NOSPEC_H
+
+/**
+ * array_index_mask_nospec() - generate a ~0 mask when index < size, 0 otherwise
+ * @index: array element index
+ * @size: number of elements in array
+ *
+ * When @index is out of bounds (@index >= @size), the sign bit will be
+ * set. Extend the sign bit to all bits and invert, giving a result of
+ * zero for an out of bounds index, or ~0 if within bounds [0, @size).
+ */
+#ifndef array_index_mask_nospec
+static inline unsigned long array_index_mask_nospec(unsigned long index,
+ unsigned long size)
+{
+ /*
+ * Warn developers about inappropriate array_index_nospec() usage.
+ *
+ * Even if the CPU speculates past the WARN_ONCE branch, the
+ * sign bit of @index is taken into account when generating the
+ * mask.
+ *
+ * This warning is compiled out when the compiler can infer that
+ * @index and @size are less than LONG_MAX.
+ */
+ if (WARN_ONCE(index > LONG_MAX || size > LONG_MAX,
+ "array_index_nospec() limited to range of [0, LONG_MAX]\n"))
+ return 0;
+
+ /*
+ * Always calculate and emit the mask even if the compiler
+ * thinks the mask is not needed. The compiler does not take
+ * into account the value of @index under speculation.
+ */
+ OPTIMIZER_HIDE_VAR(index);
+ return ~(long)(index | (size - 1UL - index)) >> (BITS_PER_LONG - 1);
+}
+#endif
+
+/*
+ * array_index_nospec - sanitize an array index after a bounds check
+ *
+ * For a code sequence like:
+ *
+ * if (index < size) {
+ * index = array_index_nospec(index, size);
+ * val = array[index];
+ * }
+ *
+ * ...if the CPU speculates past the bounds check then
+ * array_index_nospec() will clamp the index within the range of [0,
+ * size).
+ */
+#define array_index_nospec(index, size) \
+({ \
+ typeof(index) _i = (index); \
+ typeof(size) _s = (size); \
+ unsigned long _mask = array_index_mask_nospec(_i, _s); \
+ \
+ BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
+ BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \
+ \
+ _i &= _mask; \
+ _i; \
+})
+#endif /* _LINUX_NOSPEC_H */
Patches currently in stable-queue which might be from dan.j.williams(a)intel.com are
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-paravirt-remove-noreplace-paravirt-cmdline-option.patch
queue-4.9/documentation-document-array_index_nospec.patch
queue-4.9/x86-usercopy-replace-open-coded-stac-clac-with-__uaccess_-begin-end.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/vfs-fdtable-prevent-bounds-check-bypass-via-speculative-execution.patch
queue-4.9/x86-uaccess-use-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/x86-implement-array_index_mask_nospec.patch
queue-4.9/array_index_nospec-sanitize-speculative-array-de-references.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-kvm-update-spectre-v1-mitigation.patch
queue-4.9/x86-get_user-use-pointer-masking-to-limit-speculation.patch
queue-4.9/x86-syscall-sanitize-syscall-table-de-references-under-speculation.patch
queue-4.9/x86-spectre-report-get_user-mitigation-for-spectre_v1.patch
queue-4.9/x86-introduce-barrier_nospec.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-introduce-__uaccess_begin_nospec-and-uaccess_try_nospec.patch
queue-4.9/nl80211-sanitize-array-index-in-parse_txq_params.patch
This is a note to let you know that I've just added the patch titled
Documentation: Document array_index_nospec
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:
documentation-document-array_index_nospec.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 Thu Feb 8 03:32:24 CET 2018
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Mon, 29 Jan 2018 17:02:16 -0800
Subject: Documentation: Document array_index_nospec
From: Mark Rutland <mark.rutland(a)arm.com>
(cherry picked from commit f84a56f73dddaeac1dba8045b007f742f61cd2da)
Document the rationale and usage of the new array_index_nospec() helper.
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Cc: linux-arch(a)vger.kernel.org
Cc: Jonathan Corbet <corbet(a)lwn.net>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: gregkh(a)linuxfoundation.org
Cc: kernel-hardening(a)lists.openwall.com
Cc: torvalds(a)linux-foundation.org
Cc: alan(a)linux.intel.com
Link: https://lkml.kernel.org/r/151727413645.33451.15878817161436755393.stgit@dwi…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/speculation.txt | 90 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
create mode 100644 Documentation/speculation.txt
--- /dev/null
+++ b/Documentation/speculation.txt
@@ -0,0 +1,90 @@
+This document explains potential effects of speculation, and how undesirable
+effects can be mitigated portably using common APIs.
+
+===========
+Speculation
+===========
+
+To improve performance and minimize average latencies, many contemporary CPUs
+employ speculative execution techniques such as branch prediction, performing
+work which may be discarded at a later stage.
+
+Typically speculative execution cannot be observed from architectural state,
+such as the contents of registers. However, in some cases it is possible to
+observe its impact on microarchitectural state, such as the presence or
+absence of data in caches. Such state may form side-channels which can be
+observed to extract secret information.
+
+For example, in the presence of branch prediction, it is possible for bounds
+checks to be ignored by code which is speculatively executed. Consider the
+following code:
+
+ int load_array(int *array, unsigned int index)
+ {
+ if (index >= MAX_ARRAY_ELEMS)
+ return 0;
+ else
+ return array[index];
+ }
+
+Which, on arm64, may be compiled to an assembly sequence such as:
+
+ CMP <index>, #MAX_ARRAY_ELEMS
+ B.LT less
+ MOV <returnval>, #0
+ RET
+ less:
+ LDR <returnval>, [<array>, <index>]
+ RET
+
+It is possible that a CPU mis-predicts the conditional branch, and
+speculatively loads array[index], even if index >= MAX_ARRAY_ELEMS. This
+value will subsequently be discarded, but the speculated load may affect
+microarchitectural state which can be subsequently measured.
+
+More complex sequences involving multiple dependent memory accesses may
+result in sensitive information being leaked. Consider the following
+code, building on the prior example:
+
+ int load_dependent_arrays(int *arr1, int *arr2, int index)
+ {
+ int val1, val2,
+
+ val1 = load_array(arr1, index);
+ val2 = load_array(arr2, val1);
+
+ return val2;
+ }
+
+Under speculation, the first call to load_array() may return the value
+of an out-of-bounds address, while the second call will influence
+microarchitectural state dependent on this value. This may provide an
+arbitrary read primitive.
+
+====================================
+Mitigating speculation side-channels
+====================================
+
+The kernel provides a generic API to ensure that bounds checks are
+respected even under speculation. Architectures which are affected by
+speculation-based side-channels are expected to implement these
+primitives.
+
+The array_index_nospec() helper in <linux/nospec.h> can be used to
+prevent information from being leaked via side-channels.
+
+A call to array_index_nospec(index, size) returns a sanitized index
+value that is bounded to [0, size) even under cpu speculation
+conditions.
+
+This can be used to protect the earlier load_array() example:
+
+ int load_array(int *array, unsigned int index)
+ {
+ if (index >= MAX_ARRAY_ELEMS)
+ return 0;
+ else {
+ index = array_index_nospec(index, MAX_ARRAY_ELEMS);
+ return array[index];
+ }
+ }
Patches currently in stable-queue which might be from mark.rutland(a)arm.com are
queue-4.9/documentation-document-array_index_nospec.patch
This is the start of the stable review cycle for the 4.14.9 release.
There are 159 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 Sun Dec 24 08:45:36 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gz
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.9-rc1
Peter Hutterer <peter.hutterer(a)who-t.net>
platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state changes
Daniel Lezcano <daniel.lezcano(a)linaro.org>
thermal/drivers/hisi: Fix multiple alarm interrupts firing
Daniel Lezcano <daniel.lezcano(a)linaro.org>
thermal/drivers/hisi: Simplify the temperature/step computation
Daniel Lezcano <daniel.lezcano(a)linaro.org>
thermal/drivers/hisi: Fix kernel panic on alarm interrupt
Daniel Lezcano <daniel.lezcano(a)linaro.org>
thermal/drivers/hisi: Fix missing interrupt enablement
Niranjana Vishwanathapura <niranjana.vishwanathapura(a)intel.com>
IB/opa_vnic: Properly return the total MACs in UC MAC list
Scott Franco <safranco(a)intel.com>
IB/opa_vnic: Properly clear Mac Table Digest
Eric Anholt <eric(a)anholt.net>
drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math.
Nicholas Piggin <npiggin(a)gmail.com>
cpuidle: fix broadcast control when broadcast can not be entered
Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
rtc: set the alarm to the next expiring timer
Hoang Tran <tranviethoang.vn(a)gmail.com>
tcp: fix under-evaluated ssthresh in TCP Vegas
Chen-Yu Tsai <wens(a)csie.org>
clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision
Arvind Yadav <arvind.yadav.cs(a)gmail.com>
staging: greybus: light: Release memory obtained by kasprintf
Wei Hu(Xavier) <xavier.huwei(a)huawei.com>
RDMA/hns: Avoid NULL pointer exception
Mike Manning <mmanning(a)brocade.com>
net: ipv6: send NS for DAD when link operationally up
Mick Tarsel <mjtarsel(a)linux.vnet.ibm.com>
ibmvnic: Set state UP
Jacob Keller <jacob.e.keller(a)intel.com>
fm10k: ensure we process SM mbx when processing VF mbx
Marek Szyprowski <m.szyprowski(a)samsung.com>
ARM: exynos_defconfig: Enable UAS support for Odroid HC1 board
Alex Williamson <alex.williamson(a)redhat.com>
vfio/pci: Virtualize Maximum Payload Size
Alan Brady <alan.brady(a)intel.com>
i40e: fix client notify of VF reset
Dick Kennedy <dick.kennedy(a)broadcom.com>
scsi: lpfc: Fix warning messages when NVME_TARGET_FC not defined
Dick Kennedy <dick.kennedy(a)broadcom.com>
scsi: lpfc: PLOGI failures during NPIV testing
Dick Kennedy <dick.kennedy(a)broadcom.com>
scsi: lpfc: Fix secure firmware updates
Jacob Keller <jacob.e.keller(a)intel.com>
fm10k: fix mis-ordered parameters in declaration for .ndo_set_vf_bw
Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
ASoC: codecs: msm8916-wcd-analog: fix module autoload
Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
sctp: silence warns on sctp_stream_init allocations
Nicholas Piggin <npiggin(a)gmail.com>
powerpc/watchdog: Do not trigger SMP crash from touch_nmi_watchdog
Nicholas Piggin <npiggin(a)gmail.com>
powerpc/xmon: Avoid tripping SMP hardlockup watchdog
Ed Blake <ed.blake(a)sondrel.com>
ASoC: img-parallel-out: Add pm_runtime_get/put to set_fmt callback
Jean-François Têtu <jean-francois.tetu(a)savoirfairelinux.com>
ASoC: codecs: msm8916-wcd-analog: fix micbias level
Tom Zanussi <tom.zanussi(a)linux.intel.com>
tracing: Exclude 'generic fields' from histograms
Gabriele Paoloni <gabriele.paoloni(a)huawei.com>
PCI/AER: Report non-fatal errors only to the affected endpoint
Jacob Keller <jacob.e.keller(a)intel.com>
i40e/i40evf: spread CPU affinity hints across online CPUs only
Hans de Goede <hdegoede(a)redhat.com>
Bluetooth: hci_bcm: Fix setting of irq trigger type
Hans de Goede <hdegoede(a)redhat.com>
Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev
Andrew Jeffery <andrew(a)aj.id.au>
leds: pca955x: Don't invert requested value in pca955x_gpio_set_value()
Wei Wang <weiwan(a)google.com>
ipv6: grab rt->rt6i_ref before allocating pcpu rt
William Tu <u9012063(a)gmail.com>
ip_gre: check packet length and mtu correctly in erspan tx
Guoqing Jiang <gqjiang(a)suse.com>
md: always set THREAD_WAKEUP and wake up wqueue if thread existed
Luca Miccio <lucmiccio(a)gmail.com>
block,bfq: Disable writeback throttling
Colin Ian King <colin.king(a)canonical.com>
IB/rxe: check for allocation failure on elem
Emil Tantilov <emil.s.tantilov(a)intel.com>
ixgbe: fix use of uninitialized padding
Lorenzo Bianconi <lorenzo.bianconi83(a)gmail.com>
iio: st_sensors: add register mask for status register
Lihong Yang <lihong.yang(a)intel.com>
i40e: use the safe hash table iterator when deleting mac filters
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
igb: check memory allocation failure
Fabio Estevam <fabio.estevam(a)nxp.com>
PM / OPP: Move error message to debug level
Stuart Hayes <stuart.w.hayes(a)gmail.com>
PCI: Create SR-IOV virtfn/physfn links before attaching driver
Sreekanth Reddy <sreekanth.reddy(a)broadcom.com>
scsi: mpt3sas: Fix IO error occurs on pulling out a drive from RAID1 volume created on two SATA drive
Varun Prakash <varun(a)chelsio.com>
scsi: cxgb4i: fix Tx skb leak
David Daney <david.daney(a)cavium.com>
PCI: Avoid bus reset if bridge itself is broken
Dan Murphy <dmurphy(a)ti.com>
net: phy: at803x: Change error to EINVAL for invalid MAC
Shakeel Butt <shakeelb(a)google.com>
kvm, mm: account kvm related kmem slabs to kmemcg
Russell King <rmk+kernel(a)armlinux.org.uk>
rtc: pl031: make interrupt optional
Christophe Jaillet <christophe.jaillet(a)wanadoo.fr>
crypto: lrw - Fix an error handling path in 'create()'
Christian Lamparter <chunkeey(a)gmail.com>
crypto: crypto4xx - increase context and scatter ring buffer elements
Chen-Yu Tsai <wens(a)csie.org>
clk: sunxi-ng: sun5i: Fix bit offset of audio PLL post-divider
Chen-Yu Tsai <wens(a)csie.org>
clk: sunxi-ng: nm: Check if requested rate is supported by fractional clock
Shashank Sharma <shashank.sharma(a)intel.com>
drm: Add retries for lspcon mode detection
Derek Basehore <dbasehore(a)chromium.org>
backlight: pwm_bl: Fix overflow condition
Jens Wiklander <jens.wiklander(a)linaro.org>
optee: fix invalid of_node_put() in optee_driver_init()
Thomas Gleixner <tglx(a)linutronix.de>
x86/cpufeatures: Make CPU bugs sticky
Thomas Gleixner <tglx(a)linutronix.de>
x86/paravirt: Provide a way to check for hypervisors
Thomas Gleixner <tglx(a)linutronix.de>
x86/paravirt: Dont patch flush_tlb_single
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Make cpu_entry_area.tss read-only
Andy Lutomirski <luto(a)kernel.org>
x86/entry: Clean up the SYSENTER_stack code
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Remove the SYSENTER stack canary
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Move the IST stacks into struct cpu_entry_area
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Create a per-CPU SYSCALL entry trampoline
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Return to userspace from the trampoline stack
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Use a per-CPU trampoline stack for IDT entries
Andy Lutomirski <luto(a)kernel.org>
x86/espfix/64: Stop assuming that pt_regs is on the entry stack
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Separate cpu_current_top_of_stack from TSS.sp0
Andy Lutomirski <luto(a)kernel.org>
x86/entry: Remap the TSS into the CPU entry area
Andy Lutomirski <luto(a)kernel.org>
x86/entry: Move SYSENTER_stack to the beginning of struct tss_struct
Andy Lutomirski <luto(a)kernel.org>
x86/dumpstack: Handle stack overflow on all stacks
Andy Lutomirski <luto(a)kernel.org>
x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
Andy Lutomirski <luto(a)kernel.org>
x86/kasan/64: Teach KASAN about the cpu_entry_area
Andy Lutomirski <luto(a)kernel.org>
x86/mm/fixmap: Generalize the GDT fixmap mechanism, introduce struct cpu_entry_area
Andy Lutomirski <luto(a)kernel.org>
x86/entry/gdt: Put per-CPU GDT remaps in ascending order
Andy Lutomirski <luto(a)kernel.org>
x86/dumpstack: Add get_stack_info() support for the SYSENTER stack
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Allocate and enable the SYSENTER stack
Andy Lutomirski <luto(a)kernel.org>
x86/irq/64: Print the offending IP in the stack overflow warning
Andy Lutomirski <luto(a)kernel.org>
x86/irq: Remove an old outdated comment about context tracking races
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/unwinder: Handle stack overflows more gracefully
Andy Lutomirski <luto(a)kernel.org>
x86/unwinder/orc: Dont bail on stack overflow
Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
x86/entry/64/paravirt: Use paravirt-safe macro to access eflags
Andrey Ryabinin <aryabinin(a)virtuozzo.com>
x86/mm/kasan: Don't use vmemmap_populate() to initialize shadow
Will Deacon <will.deacon(a)arm.com>
locking/barriers: Convert users of lockless_dereference() to READ_ONCE()
Will Deacon <will.deacon(a)arm.com>
locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: fix build issues on um due to mising bpf_perf_event.h
Andi Kleen <ak(a)linux.intel.com>
perf/x86: Enable free running PEBS for REGS_USER/INTR
Rudolf Marek <r.marek(a)assembler.cz>
x86: Make X86_BUG_FXSAVE_LEAK detectable in CPUID on AMD
Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
x86/cpufeature: Add User-Mode Instruction Prevention definitions
Ingo Molnar <mingo(a)kernel.org>
drivers/misc/intel/pti: Rename the header file to free up the namespace
Juergen Gross <jgross(a)suse.com>
x86/virt: Add enum for hypervisors to replace x86_hyper
Juergen Gross <jgross(a)suse.com>
x86/virt, x86/platform: Merge 'struct x86_hyper' into 'struct x86_platform' and 'struct x86_init'
James Morse <james.morse(a)arm.com>
ACPI / APEI: Replace ioremap_page_range() with fixmap
Andy Lutomirski <luto(a)kernel.org>
selftests/x86/ldt_gdt: Run most existing LDT test cases against the GDT as well
Andy Lutomirski <luto(a)kernel.org>
selftests/x86/ldt_gdt: Add infrastructure to test set_thread_area()
Ingo Molnar <mingo(a)kernel.org>
x86/cpufeatures: Fix various details in the feature definitions
Ingo Molnar <mingo(a)kernel.org>
x86/cpufeatures: Re-tabulate the X86_FEATURE definitions
Borislav Petkov <bp(a)suse.de>
x86/mm: Define _PAGE_TABLE using _KERNPG_TABLE
Thomas Gleixner <tglx(a)linutronix.de>
bitops: Revert cbe96375025e ("bitops: Add clear/set_bit32() to linux/bitops.h")
Thomas Gleixner <tglx(a)linutronix.de>
x86/cpuid: Replace set/clear_bit32()
Borislav Petkov <bp(a)suse.de>
x86/entry/64: Shorten TEST instructions
Andy Lutomirski <luto(a)kernel.org>
x86/traps: Use a new on_thread_stack() helper to clean up an assertion
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Remove thread_struct::sp0
Andy Lutomirski <luto(a)kernel.org>
x86/entry/32: Fix cpu_current_top_of_stack initialization at boot
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Remove all remaining direct thread_struct::sp0 reads
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Stop initializing TSS.sp0 at boot
Andy Lutomirski <luto(a)kernel.org>
x86/xen/64, x86/entry/64: Clean up SP code in cpu_initialize_context()
Andy Lutomirski <luto(a)kernel.org>
x86/entry: Add task_top_of_stack() to find the top of a task's stack
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Pass SP0 directly to load_sp0()
Andy Lutomirski <luto(a)kernel.org>
x86/entry/32: Pull the MSR_IA32_SYSENTER_CS update code out of native_load_sp0()
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: De-Xen-ify our NMI code
Juergen Gross <jgross(a)suse.com>
xen, x86/entry/64: Add xen NMI trap entry
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Remove the RESTORE_..._REGS infrastructure
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Use POP instead of MOV to restore regs on NMI return
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Merge the fast and slow SYSRET paths
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Use pop instead of movq in syscall_return_via_sysret
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Shrink paranoid_exit_restore and make labels local
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Simplify reg restore code in the standard IRET paths
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Move SWAPGS into the common IRET-to-usermode path
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Split the IRET-to-user and IRET-to-kernel paths
Andy Lutomirski <luto(a)kernel.org>
x86/entry/64: Remove the restore_c_regs_and_iret label
Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
ptrace,x86: Make user_64bit_mode() available to 32-bit builds
Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
x86/boot: Relocate definition of the initial state of CR0
Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
x86/mm: Relocate page fault error codes to traps.h
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU features
Baoquan He <bhe(a)redhat.com>
x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'
Masahiro Yamada <yamada.masahiro(a)socionext.com>
x86/build: Beautify build log of syscall headers
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/asm: Don't use the confusing '.ifeq' directive
Dongjiu Geng <gengdongjiu(a)huawei.com>
ACPI / APEI: remove the unused dead-code for SEA/NMI notification type
Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
x86/xen: Drop 5-level paging support code from the XEN_PV code
Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
x86/xen: Provide pre-built page tables only for CONFIG_XEN_PV=y and CONFIG_XEN_PVH=y
Andrey Ryabinin <aryabinin(a)virtuozzo.com>
x86/kasan: Use the same shadow offset for 4- and 5-level paging
Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Thomas Gleixner <tglx(a)linutronix.de>
x86/cpuid: Prevent out of bound access in do_clear_cpu_cap()
Kamalesh Babulal <kamalesh(a)linux.vnet.ibm.com>
objtool: Print top level commands on incorrect usage
Kees Cook <keescook(a)chromium.org>
x86/platform/UV: Convert timers to use timer_setup()
Andi Kleen <ak(a)linux.intel.com>
x86/fpu: Remove the explicit clearing of XSAVE dependent features
Andi Kleen <ak(a)linux.intel.com>
x86/fpu: Make XSAVE check the base CPUID features before enabling
Andi Kleen <ak(a)linux.intel.com>
x86/fpu: Parse clearcpuid= as early XSAVE argument
Andi Kleen <ak(a)linux.intel.com>
x86/cpuid: Add generic table for CPUID dependencies
Andi Kleen <ak(a)linux.intel.com>
bitops: Add clear/set_bit32() to linux/bitops.h
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*'
Steven Rostedt (VMware) <rostedt(a)goodmis.org>
x86/fpu/debug: Remove unused 'x86_fpu_state' and 'x86_fpu_deactivate_state' tracepoints
Ingo Molnar <mingo(a)kernel.org>
x86/unwinder: Make CONFIG_UNWINDER_ORC=y the default in the 64-bit defconfig
Jan Beulich <JBeulich(a)suse.com>
ACPI / APEI: adjust a local variable type in ghes_ioremap_pfn_irq()
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/head: Add unwind hint annotations
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/xen: Add unwind hint annotations
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/xen: Fix xen head ELF annotations
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/boot: Annotate verify_cpu() as a callable function
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/head: Fix head ELF function annotations
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/head: Remove unused 'bad_address' code
Josh Poimboeuf <jpoimboe(a)redhat.com>
x86/head: Remove confusing comment
Josh Poimboeuf <jpoimboe(a)redhat.com>
objtool: Don't report end of section error after an empty unwind hint
Uros Bizjak <ubizjak(a)gmail.com>
x86/asm: Remove unnecessary \n\t in front of CC_SET() from asm templates
-------------
Diffstat:
Documentation/x86/orc-unwinder.txt | 2 +-
Documentation/x86/x86_64/mm.txt | 2 +-
Makefile | 8 +-
arch/arm/configs/exynos_defconfig | 2 +-
arch/arm64/include/asm/fixmap.h | 7 +
arch/powerpc/kernel/watchdog.c | 7 +-
arch/powerpc/xmon/xmon.c | 17 +-
arch/um/include/asm/Kbuild | 1 +
arch/x86/Kconfig | 5 +-
arch/x86/Kconfig.debug | 39 +-
arch/x86/configs/tiny.config | 4 +-
arch/x86/configs/x86_64_defconfig | 1 +
arch/x86/entry/calling.h | 69 +--
arch/x86/entry/entry_32.S | 6 +-
arch/x86/entry/entry_64.S | 322 +++++++++---
arch/x86/entry/entry_64_compat.S | 10 +-
arch/x86/entry/syscalls/Makefile | 4 +-
arch/x86/events/core.c | 2 +-
arch/x86/events/intel/core.c | 4 +
arch/x86/events/perf_event.h | 24 +-
arch/x86/hyperv/hv_init.c | 2 +-
arch/x86/include/asm/archrandom.h | 8 +-
arch/x86/include/asm/bitops.h | 10 +-
arch/x86/include/asm/compat.h | 1 +
arch/x86/include/asm/cpufeature.h | 11 +-
arch/x86/include/asm/cpufeatures.h | 538 +++++++++++----------
arch/x86/include/asm/desc.h | 11 +-
arch/x86/include/asm/fixmap.h | 74 ++-
arch/x86/include/asm/hypervisor.h | 53 +-
arch/x86/include/asm/irqflags.h | 3 +
arch/x86/include/asm/kdebug.h | 1 +
arch/x86/include/asm/mmu_context.h | 4 +-
arch/x86/include/asm/module.h | 2 +-
arch/x86/include/asm/paravirt.h | 14 +-
arch/x86/include/asm/paravirt_types.h | 2 +-
arch/x86/include/asm/percpu.h | 2 +-
arch/x86/include/asm/pgtable_types.h | 3 +-
arch/x86/include/asm/processor.h | 109 +++--
arch/x86/include/asm/ptrace.h | 6 +-
arch/x86/include/asm/rmwcc.h | 2 +-
arch/x86/include/asm/stacktrace.h | 3 +
arch/x86/include/asm/switch_to.h | 26 +
arch/x86/include/asm/thread_info.h | 2 +-
arch/x86/include/asm/trace/fpu.h | 10 -
arch/x86/include/asm/traps.h | 21 +-
arch/x86/include/asm/unwind.h | 15 +-
arch/x86/include/asm/x86_init.h | 24 +
arch/x86/include/uapi/asm/processor-flags.h | 3 +
arch/x86/kernel/Makefile | 10 +-
arch/x86/kernel/apic/apic.c | 2 +-
arch/x86/kernel/apic/x2apic_uv_x.c | 5 +-
arch/x86/kernel/asm-offsets.c | 6 +
arch/x86/kernel/asm-offsets_32.c | 9 +-
arch/x86/kernel/asm-offsets_64.c | 4 +
arch/x86/kernel/cpu/Makefile | 1 +
arch/x86/kernel/cpu/amd.c | 7 +-
arch/x86/kernel/cpu/common.c | 195 +++++---
arch/x86/kernel/cpu/cpuid-deps.c | 121 +++++
arch/x86/kernel/cpu/hypervisor.c | 64 +--
arch/x86/kernel/cpu/mshyperv.c | 6 +-
arch/x86/kernel/cpu/vmware.c | 8 +-
arch/x86/kernel/doublefault.c | 36 +-
arch/x86/kernel/dumpstack.c | 74 ++-
arch/x86/kernel/dumpstack_32.c | 6 +
arch/x86/kernel/dumpstack_64.c | 6 +
arch/x86/kernel/fpu/init.c | 11 +
arch/x86/kernel/fpu/xstate.c | 43 +-
arch/x86/kernel/head_32.S | 5 +-
arch/x86/kernel/head_64.S | 45 +-
arch/x86/kernel/ioport.c | 2 +-
arch/x86/kernel/irq.c | 12 -
arch/x86/kernel/irq_64.c | 4 +-
arch/x86/kernel/kvm.c | 6 +-
arch/x86/kernel/ldt.c | 2 +-
arch/x86/kernel/paravirt_patch_64.c | 2 -
arch/x86/kernel/process.c | 27 +-
arch/x86/kernel/process_32.c | 8 +-
arch/x86/kernel/process_64.c | 19 +-
arch/x86/kernel/smpboot.c | 3 +-
arch/x86/kernel/traps.c | 72 +--
arch/x86/kernel/unwind_orc.c | 88 ++--
arch/x86/kernel/verify_cpu.S | 3 +-
arch/x86/kernel/vm86_32.c | 20 +-
arch/x86/kernel/vmlinux.lds.S | 9 +
arch/x86/kernel/x86_init.c | 9 +
arch/x86/kvm/mmu.c | 4 +-
arch/x86/kvm/vmx.c | 2 +-
arch/x86/lib/delay.c | 4 +-
arch/x86/mm/fault.c | 88 ++--
arch/x86/mm/init.c | 2 +-
arch/x86/mm/init_64.c | 10 +-
arch/x86/mm/kasan_init_64.c | 262 ++++++++--
arch/x86/power/cpu.c | 16 +-
arch/x86/xen/enlighten_hvm.c | 12 +-
arch/x86/xen/enlighten_pv.c | 15 +-
arch/x86/xen/mmu_pv.c | 161 +++---
arch/x86/xen/smp_pv.c | 17 +-
arch/x86/xen/xen-asm_64.S | 2 +-
arch/x86/xen/xen-head.S | 11 +-
block/bfq-iosched.c | 3 +-
block/blk-wbt.c | 2 +-
crypto/lrw.c | 6 +-
drivers/acpi/apei/ghes.c | 78 +--
drivers/base/power/opp/core.c | 2 +-
drivers/bluetooth/hci_bcm.c | 23 +-
drivers/bluetooth/hci_ldisc.c | 7 +
drivers/clk/sunxi-ng/ccu-sun5i.c | 4 +-
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +-
drivers/clk/sunxi-ng/ccu_nm.c | 3 +
drivers/cpuidle/cpuidle.c | 1 +
drivers/crypto/amcc/crypto4xx_core.h | 10 +-
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 16 +-
drivers/gpu/drm/vc4/vc4_dsi.c | 3 +-
drivers/hv/vmbus_drv.c | 2 +-
drivers/iio/accel/st_accel_core.c | 35 +-
drivers/iio/common/st_sensors/st_sensors_core.c | 2 +-
drivers/iio/common/st_sensors/st_sensors_trigger.c | 16 +-
drivers/iio/gyro/st_gyro_core.c | 15 +-
drivers/iio/magnetometer/st_magn_core.c | 10 +-
drivers/iio/pressure/st_pressure_core.c | 15 +-
drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 5 +
drivers/infiniband/sw/rxe/rxe_pool.c | 2 +
drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.c | 1 +
.../infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c | 8 +-
drivers/input/mouse/vmmouse.c | 10 +-
drivers/leds/leds-pca955x.c | 17 +-
drivers/md/dm-mpath.c | 20 +-
drivers/md/md.c | 4 +-
drivers/misc/pti.c | 2 +-
drivers/misc/vmw_balloon.c | 2 +-
drivers/net/ethernet/ibm/ibmvnic.c | 2 +
drivers/net/ethernet/intel/fm10k/fm10k.h | 4 +-
drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 12 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 16 +-
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 9 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 +
drivers/net/phy/at803x.c | 2 +-
drivers/pci/iov.c | 3 +-
drivers/pci/pci.c | 4 +
drivers/pci/pcie/aer/aerdrv_core.c | 9 +-
drivers/platform/x86/asus-wireless.c | 1 +
drivers/rtc/interface.c | 2 +-
drivers/rtc/rtc-pl031.c | 14 +-
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 1 +
drivers/scsi/lpfc/lpfc_hbadisc.c | 3 +-
drivers/scsi/lpfc/lpfc_hw4.h | 2 +-
drivers/scsi/lpfc/lpfc_nvmet.c | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 5 +
drivers/staging/greybus/light.c | 2 +
drivers/tee/optee/core.c | 1 -
drivers/thermal/hisi_thermal.c | 74 ++-
drivers/vfio/pci/vfio_pci_config.c | 6 +-
drivers/video/backlight/pwm_bl.c | 7 +-
fs/dcache.c | 4 +-
fs/overlayfs/ovl_entry.h | 2 +-
fs/overlayfs/readdir.c | 2 +-
include/asm-generic/vmlinux.lds.h | 2 +-
include/linux/compiler.h | 1 +
include/linux/hypervisor.h | 8 +-
include/linux/iio/common/st_sensors.h | 7 +-
include/linux/{pti.h => intel-pti.h} | 6 +-
include/linux/mm.h | 2 +-
include/linux/mmzone.h | 6 +-
include/linux/rculist.h | 4 +-
include/linux/rcupdate.h | 4 +-
kernel/events/core.c | 4 +-
kernel/seccomp.c | 2 +-
kernel/task_work.c | 2 +-
kernel/trace/trace_events_hist.c | 4 +-
lib/Kconfig.debug | 2 +-
mm/page_alloc.c | 10 +
mm/slab.h | 2 +-
mm/sparse.c | 17 +-
net/ipv4/ip_gre.c | 8 +-
net/ipv4/tcp_vegas.c | 2 +-
net/ipv6/addrconf.c | 12 +-
net/ipv6/route.c | 58 +--
net/sctp/stream.c | 8 +-
scripts/Makefile.build | 2 +-
sound/soc/codecs/msm8916-wcd-analog.c | 9 +-
sound/soc/img/img-parallel-out.c | 2 +
tools/objtool/check.c | 7 +-
tools/objtool/objtool.c | 6 +-
tools/testing/selftests/x86/ldt_gdt.c | 61 ++-
virt/kvm/kvm_main.c | 2 +-
188 files changed, 2414 insertions(+), 1428 deletions(-)
This is a note to let you know that I've just added the patch titled
x86/retpoline: Remove the esp/rsp thunk
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-retpoline-remove-the-esp-rsp-thunk.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 19:38:23 CST 2018
From: Waiman Long <longman(a)redhat.com>
Date: Mon, 22 Jan 2018 17:09:34 -0500
Subject: x86/retpoline: Remove the esp/rsp thunk
From: Waiman Long <longman(a)redhat.com>
(cherry picked from commit 1df37383a8aeabb9b418698f0bcdffea01f4b1b2)
It doesn't make sense to have an indirect call thunk with esp/rsp as
retpoline code won't work correctly with the stack pointer register.
Removing it will help compiler writers to catch error in case such
a thunk call is emitted incorrectly.
Fixes: 76b043848fd2 ("x86/retpoline: Add initial retpoline support")
Suggested-by: Jeff Law <law(a)redhat.com>
Signed-off-by: Waiman Long <longman(a)redhat.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: David Woodhouse <dwmw(a)amazon.co.uk>
Cc: Tom Lendacky <thomas.lendacky(a)amd.com>
Cc: Kees Cook <keescook(a)google.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Jiri Kosina <jikos(a)kernel.org>
Cc: Andy Lutomirski <luto(a)amacapital.net>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linux-foundation.org>
Cc: Paul Turner <pjt(a)google.com>
Link: https://lkml.kernel.org/r/1516658974-27852-1-git-send-email-longman@redhat.…
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/asm-prototypes.h | 1 -
arch/x86/lib/retpoline.S | 1 -
2 files changed, 2 deletions(-)
--- a/arch/x86/include/asm/asm-prototypes.h
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -37,5 +37,4 @@ INDIRECT_THUNK(dx)
INDIRECT_THUNK(si)
INDIRECT_THUNK(di)
INDIRECT_THUNK(bp)
-INDIRECT_THUNK(sp)
#endif /* CONFIG_RETPOLINE */
--- a/arch/x86/lib/retpoline.S
+++ b/arch/x86/lib/retpoline.S
@@ -36,7 +36,6 @@ GENERATE_THUNK(_ASM_DX)
GENERATE_THUNK(_ASM_SI)
GENERATE_THUNK(_ASM_DI)
GENERATE_THUNK(_ASM_BP)
-GENERATE_THUNK(_ASM_SP)
#ifdef CONFIG_64BIT
GENERATE_THUNK(r8)
GENERATE_THUNK(r9)
Patches currently in stable-queue which might be from longman(a)redhat.com are
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
This is a note to let you know that I've just added the patch titled
x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 19:38:23 CST 2018
From: David Woodhouse <dwmw(a)amazon.co.uk>
Date: Thu, 25 Jan 2018 16:14:13 +0000
Subject: x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
From: David Woodhouse <dwmw(a)amazon.co.uk>
(cherry picked from commit fec9434a12f38d3aeafeb75711b71d8a1fdef621)
Also, for CPUs which don't speculate at all, don't report that they're
vulnerable to the Spectre variants either.
Leave the cpu_no_meltdown[] match table with just X86_VENDOR_AMD in it
for now, even though that could be done with a simple comparison, on the
assumption that we'll have more to add.
Based on suggestions from Dave Hansen and Alan Cox.
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Reviewed-by: Borislav Petkov <bp(a)suse.de>
Acked-by: Dave Hansen <dave.hansen(a)intel.com>
Cc: gnomes(a)lxorguk.ukuu.org.uk
Cc: ak(a)linux.intel.com
Cc: ashok.raj(a)intel.com
Cc: karahmed(a)amazon.de
Cc: arjan(a)linux.intel.com
Cc: torvalds(a)linux-foundation.org
Cc: peterz(a)infradead.org
Cc: bp(a)alien8.de
Cc: pbonzini(a)redhat.com
Cc: tim.c.chen(a)linux.intel.com
Cc: gregkh(a)linux-foundation.org
Link: https://lkml.kernel.org/r/1516896855-7642-6-git-send-email-dwmw@amazon.co.uk
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/common.c | 48 ++++++++++++++++++++++++++++++++++++++-----
1 file changed, 43 insertions(+), 5 deletions(-)
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -44,6 +44,8 @@
#include <asm/pat.h>
#include <asm/microcode.h>
#include <asm/microcode_intel.h>
+#include <asm/intel-family.h>
+#include <asm/cpu_device_id.h>
#ifdef CONFIG_X86_LOCAL_APIC
#include <asm/uv/uv.h>
@@ -838,6 +840,41 @@ static void identify_cpu_without_cpuid(s
#endif
}
+static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY },
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL, X86_FEATURE_ANY },
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY },
+ { X86_VENDOR_CENTAUR, 5 },
+ { X86_VENDOR_INTEL, 5 },
+ { X86_VENDOR_NSC, 5 },
+ { X86_VENDOR_ANY, 4 },
+ {}
+};
+
+static const __initdata struct x86_cpu_id cpu_no_meltdown[] = {
+ { X86_VENDOR_AMD },
+ {}
+};
+
+static bool __init cpu_vulnerable_to_meltdown(struct cpuinfo_x86 *c)
+{
+ u64 ia32_cap = 0;
+
+ if (x86_match_cpu(cpu_no_meltdown))
+ return false;
+
+ if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
+ rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
+
+ /* Rogue Data Cache Load? No! */
+ if (ia32_cap & ARCH_CAP_RDCL_NO)
+ return false;
+
+ return true;
+}
+
/*
* Do minimum CPU detection early.
* Fields really needed: vendor, cpuid_level, family, model, mask,
@@ -884,11 +921,12 @@ static void __init early_identify_cpu(st
setup_force_cpu_cap(X86_FEATURE_ALWAYS);
- if (c->x86_vendor != X86_VENDOR_AMD)
- setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN);
-
- setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
- setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
+ if (!x86_match_cpu(cpu_no_speculation)) {
+ if (cpu_vulnerable_to_meltdown(c))
+ setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN);
+ setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
+ setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
+ }
fpu__init_system(c);
Patches currently in stable-queue which might be from dwmw(a)amazon.co.uk are
queue-4.9/kvm-vmx-introduce-alloc_loaded_vmcs.patch
queue-4.9/kvm-nvmx-eliminate-vmcs02-pool.patch
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-cpufeature-blacklist-spec_ctrl-pred_cmd-on-early-spectre-v2-microcodes.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
queue-4.9/module-retpoline-warn-about-missing-retpoline-in-module.patch
queue-4.9/kvm-nvmx-vmx_complete_nested_posted_interrupt-can-t-fail.patch
queue-4.9/x86-msr-add-definitions-for-new-speculation-control-msrs.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/kvm-vmx-make-msr-bitmaps-per-vcpu.patch
queue-4.9/kvm-nvmx-mark-vmcs12-pages-dirty-on-l2-exit.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
This is a note to let you know that I've just added the patch titled
x86/msr: Add definitions for new speculation control MSRs
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-msr-add-definitions-for-new-speculation-control-msrs.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 19:38:23 CST 2018
From: David Woodhouse <dwmw(a)amazon.co.uk>
Date: Thu, 25 Jan 2018 16:14:12 +0000
Subject: x86/msr: Add definitions for new speculation control MSRs
From: David Woodhouse <dwmw(a)amazon.co.uk>
(cherry picked from commit 1e340c60d0dd3ae07b5bedc16a0469c14b9f3410)
Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES.
See Intel's 336996-Speculative-Execution-Side-Channel-Mitigations.pdf
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: gnomes(a)lxorguk.ukuu.org.uk
Cc: ak(a)linux.intel.com
Cc: ashok.raj(a)intel.com
Cc: dave.hansen(a)intel.com
Cc: karahmed(a)amazon.de
Cc: arjan(a)linux.intel.com
Cc: torvalds(a)linux-foundation.org
Cc: peterz(a)infradead.org
Cc: bp(a)alien8.de
Cc: pbonzini(a)redhat.com
Cc: tim.c.chen(a)linux.intel.com
Cc: gregkh(a)linux-foundation.org
Link: https://lkml.kernel.org/r/1516896855-7642-5-git-send-email-dwmw@amazon.co.uk
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/msr-index.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -37,6 +37,13 @@
#define EFER_FFXSR (1<<_EFER_FFXSR)
/* Intel MSRs. Some also available on other CPUs */
+#define MSR_IA32_SPEC_CTRL 0x00000048 /* Speculation Control */
+#define SPEC_CTRL_IBRS (1 << 0) /* Indirect Branch Restricted Speculation */
+#define SPEC_CTRL_STIBP (1 << 1) /* Single Thread Indirect Branch Predictors */
+
+#define MSR_IA32_PRED_CMD 0x00000049 /* Prediction Command */
+#define PRED_CMD_IBPB (1 << 0) /* Indirect Branch Prediction Barrier */
+
#define MSR_IA32_PERFCTR0 0x000000c1
#define MSR_IA32_PERFCTR1 0x000000c2
#define MSR_FSB_FREQ 0x000000cd
@@ -50,6 +57,11 @@
#define SNB_C3_AUTO_UNDEMOTE (1UL << 28)
#define MSR_MTRRcap 0x000000fe
+
+#define MSR_IA32_ARCH_CAPABILITIES 0x0000010a
+#define ARCH_CAP_RDCL_NO (1 << 0) /* Not susceptible to Meltdown */
+#define ARCH_CAP_IBRS_ALL (1 << 1) /* Enhanced IBRS support */
+
#define MSR_IA32_BBL_CR_CTL 0x00000119
#define MSR_IA32_BBL_CR_CTL3 0x0000011e
Patches currently in stable-queue which might be from dwmw(a)amazon.co.uk are
queue-4.9/kvm-vmx-introduce-alloc_loaded_vmcs.patch
queue-4.9/kvm-nvmx-eliminate-vmcs02-pool.patch
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-cpufeature-blacklist-spec_ctrl-pred_cmd-on-early-spectre-v2-microcodes.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
queue-4.9/module-retpoline-warn-about-missing-retpoline-in-module.patch
queue-4.9/kvm-nvmx-vmx_complete_nested_posted_interrupt-can-t-fail.patch
queue-4.9/x86-msr-add-definitions-for-new-speculation-control-msrs.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/kvm-vmx-make-msr-bitmaps-per-vcpu.patch
queue-4.9/kvm-nvmx-mark-vmcs12-pages-dirty-on-l2-exit.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
This is a note to let you know that I've just added the patch titled
x86/cpufeatures: Add Intel feature bits for Speculation Control
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 19:38:23 CST 2018
From: David Woodhouse <dwmw(a)amazon.co.uk>
Date: Thu, 25 Jan 2018 16:14:10 +0000
Subject: x86/cpufeatures: Add Intel feature bits for Speculation Control
From: David Woodhouse <dwmw(a)amazon.co.uk>
(cherry picked from commit fc67dd70adb711a45d2ef34e12d1a8be75edde61)
Add three feature bits exposed by new microcode on Intel CPUs for
speculation control.
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Reviewed-by: Borislav Petkov <bp(a)suse.de>
Cc: gnomes(a)lxorguk.ukuu.org.uk
Cc: ak(a)linux.intel.com
Cc: ashok.raj(a)intel.com
Cc: dave.hansen(a)intel.com
Cc: karahmed(a)amazon.de
Cc: arjan(a)linux.intel.com
Cc: torvalds(a)linux-foundation.org
Cc: peterz(a)infradead.org
Cc: bp(a)alien8.de
Cc: pbonzini(a)redhat.com
Cc: tim.c.chen(a)linux.intel.com
Cc: gregkh(a)linux-foundation.org
Link: https://lkml.kernel.org/r/1516896855-7642-3-git-send-email-dwmw@amazon.co.uk
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/cpufeatures.h | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -296,6 +296,9 @@
/* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */
#define X86_FEATURE_AVX512_4VNNIW (18*32+ 2) /* AVX-512 Neural Network Instructions */
#define X86_FEATURE_AVX512_4FMAPS (18*32+ 3) /* AVX-512 Multiply Accumulation Single precision */
+#define X86_FEATURE_SPEC_CTRL (18*32+26) /* Speculation Control (IBRS + IBPB) */
+#define X86_FEATURE_STIBP (18*32+27) /* Single Thread Indirect Branch Predictors */
+#define X86_FEATURE_ARCH_CAPABILITIES (18*32+29) /* IA32_ARCH_CAPABILITIES MSR (Intel) */
/*
* BUG word(s)
Patches currently in stable-queue which might be from dwmw(a)amazon.co.uk are
queue-4.9/kvm-vmx-introduce-alloc_loaded_vmcs.patch
queue-4.9/kvm-nvmx-eliminate-vmcs02-pool.patch
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-cpufeature-blacklist-spec_ctrl-pred_cmd-on-early-spectre-v2-microcodes.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
queue-4.9/module-retpoline-warn-about-missing-retpoline-in-module.patch
queue-4.9/kvm-nvmx-vmx_complete_nested_posted_interrupt-can-t-fail.patch
queue-4.9/x86-msr-add-definitions-for-new-speculation-control-msrs.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/kvm-vmx-make-msr-bitmaps-per-vcpu.patch
queue-4.9/kvm-nvmx-mark-vmcs12-pages-dirty-on-l2-exit.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
This is a note to let you know that I've just added the patch titled
x86/cpufeatures: Add AMD feature bits for Speculation Control
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 19:38:23 CST 2018
From: David Woodhouse <dwmw(a)amazon.co.uk>
Date: Thu, 25 Jan 2018 16:14:11 +0000
Subject: x86/cpufeatures: Add AMD feature bits for Speculation Control
From: David Woodhouse <dwmw(a)amazon.co.uk>
(cherry picked from commit 5d10cbc91d9eb5537998b65608441b592eec65e7)
AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel.
See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-aeaf-9ac4aae39de8@amd.com
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Tom Lendacky <thomas.lendacky(a)amd.com>
Cc: gnomes(a)lxorguk.ukuu.org.uk
Cc: ak(a)linux.intel.com
Cc: ashok.raj(a)intel.com
Cc: dave.hansen(a)intel.com
Cc: karahmed(a)amazon.de
Cc: arjan(a)linux.intel.com
Cc: torvalds(a)linux-foundation.org
Cc: peterz(a)infradead.org
Cc: bp(a)alien8.de
Cc: pbonzini(a)redhat.com
Cc: tim.c.chen(a)linux.intel.com
Cc: gregkh(a)linux-foundation.org
Link: https://lkml.kernel.org/r/1516896855-7642-4-git-send-email-dwmw@amazon.co.uk
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/cpufeatures.h | 3 +++
1 file changed, 3 insertions(+)
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -258,6 +258,9 @@
/* AMD-defined CPU features, CPUID level 0x80000008 (ebx), word 13 */
#define X86_FEATURE_CLZERO (13*32+0) /* CLZERO instruction */
#define X86_FEATURE_IRPERF (13*32+1) /* Instructions Retired Count */
+#define X86_FEATURE_AMD_PRED_CMD (13*32+12) /* Prediction Command MSR (AMD) */
+#define X86_FEATURE_AMD_SPEC_CTRL (13*32+14) /* Speculation Control MSR only (AMD) */
+#define X86_FEATURE_AMD_STIBP (13*32+15) /* Single Thread Indirect Branch Predictors (AMD) */
/* Thermal and Power Management Leaf, CPUID level 0x00000006 (eax), word 14 */
#define X86_FEATURE_DTHERM (14*32+ 0) /* Digital Thermal Sensor */
Patches currently in stable-queue which might be from dwmw(a)amazon.co.uk are
queue-4.9/kvm-vmx-introduce-alloc_loaded_vmcs.patch
queue-4.9/kvm-nvmx-eliminate-vmcs02-pool.patch
queue-4.9/kvm-vmx-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/kvm-svm-allow-direct-access-to-msr_ia32_spec_ctrl.patch
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-cpufeature-blacklist-spec_ctrl-pred_cmd-on-early-spectre-v2-microcodes.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
queue-4.9/module-retpoline-warn-about-missing-retpoline-in-module.patch
queue-4.9/kvm-nvmx-vmx_complete_nested_posted_interrupt-can-t-fail.patch
queue-4.9/x86-msr-add-definitions-for-new-speculation-control-msrs.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/kvm-vmx-make-msr-bitmaps-per-vcpu.patch
queue-4.9/kvm-nvmx-mark-vmcs12-pages-dirty-on-l2-exit.patch
queue-4.9/kvm-vmx-emulate-msr_ia32_arch_capabilities.patch
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: Make indirect calls in emulator speculation safe
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 19:38:23 CST 2018
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Thu, 25 Jan 2018 10:58:13 +0100
Subject: KVM: x86: Make indirect calls in emulator speculation safe
From: Peter Zijlstra <peterz(a)infradead.org>
(cherry picked from commit 1a29b5b7f347a1a9230c1e0af5b37e3e571588ab)
Replace the indirect calls with CALL_NOSPEC.
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: David Woodhouse <dwmw(a)amazon.co.uk>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Ashok Raj <ashok.raj(a)intel.com>
Cc: Greg KH <gregkh(a)linuxfoundation.org>
Cc: Jun Nakajima <jun.nakajima(a)intel.com>
Cc: David Woodhouse <dwmw2(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: rga(a)amazon.de
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Asit Mallick <asit.k.mallick(a)intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Jason Baron <jbaron(a)akamai.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: Arjan Van De Ven <arjan.van.de.ven(a)intel.com>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Link: https://lkml.kernel.org/r/20180125095843.595615683@infradead.org
[dwmw2: Use ASM_CALL_CONSTRAINT like upstream, now we have it]
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/emulate.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -25,6 +25,7 @@
#include <asm/kvm_emulate.h>
#include <linux/stringify.h>
#include <asm/debugreg.h>
+#include <asm/nospec-branch.h>
#include "x86.h"
#include "tss.h"
@@ -1012,8 +1013,8 @@ static __always_inline u8 test_cc(unsign
void (*fop)(void) = (void *)em_setcc + 4 * (condition & 0xf);
flags = (flags & EFLAGS_MASK) | X86_EFLAGS_IF;
- asm("push %[flags]; popf; call *%[fastop]"
- : "=a"(rc) : [fastop]"r"(fop), [flags]"r"(flags));
+ asm("push %[flags]; popf; " CALL_NOSPEC
+ : "=a"(rc) : [thunk_target]"r"(fop), [flags]"r"(flags));
return rc;
}
@@ -5306,15 +5307,14 @@ static void fetch_possible_mmx_operand(s
static int fastop(struct x86_emulate_ctxt *ctxt, void (*fop)(struct fastop *))
{
- register void *__sp asm(_ASM_SP);
ulong flags = (ctxt->eflags & EFLAGS_MASK) | X86_EFLAGS_IF;
if (!(ctxt->d & ByteOp))
fop += __ffs(ctxt->dst.bytes) * FASTOP_SIZE;
- asm("push %[flags]; popf; call *%[fastop]; pushf; pop %[flags]\n"
+ asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n"
: "+a"(ctxt->dst.val), "+d"(ctxt->src.val), [flags]"+D"(flags),
- [fastop]"+S"(fop), "+r"(__sp)
+ [thunk_target]"+S"(fop), ASM_CALL_CONSTRAINT
: "c"(ctxt->src2.val));
ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK);
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-cpufeature-blacklist-spec_ctrl-pred_cmd-on-early-spectre-v2-microcodes.patch
queue-4.9/x86-asm-fix-inline-asm-call-constraints-for-gcc-4.4.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
queue-4.9/x86-msr-add-definitions-for-new-speculation-control-msrs.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/kaiser-fix-intel_bts-perf-crashes.patch
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
This is a note to let you know that I've just added the patch titled
KVM: VMX: Make indirect call speculation safe
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-vmx-make-indirect-call-speculation-safe.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 19:38:23 CST 2018
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Thu, 25 Jan 2018 10:58:14 +0100
Subject: KVM: VMX: Make indirect call speculation safe
From: Peter Zijlstra <peterz(a)infradead.org>
(cherry picked from commit c940a3fb1e2e9b7d03228ab28f375fb5a47ff699)
Replace indirect call with CALL_NOSPEC.
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: David Woodhouse <dwmw(a)amazon.co.uk>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Ashok Raj <ashok.raj(a)intel.com>
Cc: Greg KH <gregkh(a)linuxfoundation.org>
Cc: Jun Nakajima <jun.nakajima(a)intel.com>
Cc: David Woodhouse <dwmw2(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: rga(a)amazon.de
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Asit Mallick <asit.k.mallick(a)intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Jason Baron <jbaron(a)akamai.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: Arjan Van De Ven <arjan.van.de.ven(a)intel.com>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Link: https://lkml.kernel.org/r/20180125095843.645776917@infradead.org
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8676,14 +8676,14 @@ static void vmx_handle_external_intr(str
#endif
"pushf\n\t"
__ASM_SIZE(push) " $%c[cs]\n\t"
- "call *%[entry]\n\t"
+ CALL_NOSPEC
:
#ifdef CONFIG_X86_64
[sp]"=&r"(tmp),
#endif
"+r"(__sp)
:
- [entry]"r"(entry),
+ THUNK_TARGET(entry),
[ss]"i"(__KERNEL_DS),
[cs]"i"(__KERNEL_CS)
);
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.9/kvm-x86-add-ibpb-support.patch
queue-4.9/x86-cpufeatures-add-intel-feature-bits-for-speculation-control.patch
queue-4.9/x86-cpufeatures-add-cpuid_7_edx-cpuid-leaf.patch
queue-4.9/kvm-x86-make-indirect-calls-in-emulator-speculation-safe.patch
queue-4.9/x86-cpufeature-blacklist-spec_ctrl-pred_cmd-on-early-spectre-v2-microcodes.patch
queue-4.9/x86-asm-fix-inline-asm-call-constraints-for-gcc-4.4.patch
queue-4.9/kvm-vmx-make-indirect-call-speculation-safe.patch
queue-4.9/x86-cpufeatures-add-amd-feature-bits-for-speculation-control.patch
queue-4.9/x86-msr-add-definitions-for-new-speculation-control-msrs.patch
queue-4.9/x86-pti-make-unpoison-of-pgd-for-trusted-boot-work-for-real.patch
queue-4.9/kaiser-fix-intel_bts-perf-crashes.patch
queue-4.9/x86-retpoline-remove-the-esp-rsp-thunk.patch
queue-4.9/x86-pti-do-not-enable-pti-on-cpus-which-are-not-vulnerable-to-meltdown.patch
Hello, I am not familiar with Linux mailing, sorry for this.
I am writing this mail because I am not sure about commit
6c16fa957e84c8b640dadc4e0264ff0d2dae7aa3 added in 3.18.93.
That backport made the arp.h changes in struct __ipv4_neigh_lookup(),
but compared with upstream commit, I think that 3 lines should be
added in __ipv4_neigh_lookup_noref(), as I go through the context.
Also the latter would be called unconditionally if former is called so
it would cover more cases.
Could you please check this and let me know? Though it would 90% be my derp.
Thanks,
Wang
As discussed earlier,
From: Wang Han <wanghan1995315(a)gmail.com>
Date: Sat, 3 Feb 2018 03:28:35 +1400
Subject: [PATCH] ipv4: Map neigh lookup keys in __ipv4_neigh_lookup_noref()
Commit 6c16fa957e84 is an incorrect backport as we map the keys in
struct __ipv4_neigh_lookup(), but the correct place to add the
code is struct __ipv4_neigh_lookup_noref(), compared to upstream.
Fix it by moving the code, or fewer cases will be covered as
__ipv4_neigh_lookup_noref() will be called unconditionally from
__ipv4_neigh_lookup(), and it can be called from other places
such as ip_output.c.
Fixes: 6c16fa957e84 (ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY)
Signed-off-by: Wang Han <wanghan1995315(a)gmail.com>
---
include/net/arp.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/arp.h b/include/net/arp.h
index 174014585ade..5d8c7990582f 100644
--- a/include/net/arp.h
+++ b/include/net/arp.h
@@ -22,6 +22,9 @@ static inline struct neighbour *__ipv4_neigh_lookup_noref(struct net_device *dev
struct neighbour *n;
u32 hash_val;
+ if (dev->flags & (IFF_LOOPBACK | IFF_POINTOPOINT))
+ key = INADDR_ANY;
+
hash_val = arp_hashfn(key, dev, nht->hash_rnd[0]) >> (32 - nht->hash_shift);
for (n = rcu_dereference_bh(nht->hash_buckets[hash_val]);
n != NULL;
@@ -37,9 +40,6 @@ static inline struct neighbour *__ipv4_neigh_lookup(struct net_device *dev, u32
{
struct neighbour *n;
- if (dev->flags & (IFF_LOOPBACK | IFF_POINTOPOINT))
- key = INADDR_ANY;
-
rcu_read_lock_bh();
n = __ipv4_neigh_lookup_noref(dev, key);
if (n && !atomic_inc_not_zero(&n->refcnt))
--
2.14.1
On Wed, Feb 07, 2018 at 03:19:07PM +0000, Harsh Shandilya wrote:
> On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, <gregkh(a)linuxfoundation.org>
> wrote:
>
> > This is the start of the stable review cycle for the 3.18.94 release.
> > There are 36 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 7 18:23:41 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> Let's find out if I am too late.
>
> https://www.spinics.net/lists/stable/msg213160.html will have to be lined
> up for 3.18.94, or to .95 if I'm late since it's fixing a erroneous
> backport from 3.18.93 which went unnoticed until after release. The email
> bringing it up and the subsequent patch were probably lost in the usual
> stable noise. I have applied it to the CAF tree for the oneplus3 and
> verified that it does not break compilation or userspace for arm64.
It will be queued up for the next release, I missed it this time, sorry.
greg k-h
On Sat, Feb 03, 2018 at 07:25:54PM +0100, Markus Demleitner wrote:
> On Tue, Jan 30, 2018 at 07:32:04AM +0100, Greg KH wrote:
> > On Mon, Jan 29, 2018 at 07:21:09PM +0100, Markus Demleitner wrote:
> > > A while ago I opened bug #197863 in the kernel bugzilla:
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=197863
> > >
> > > Essentially, xhci_hcd on a resume from RAM takes several seconds on a
> > > Thinkpad X240 that is equipped with a Sierra LTE modem after an
> > > upgrade to 4.13:
> [...]
> > > Now, interestingly, there are quick resumes in 4.15.0, too, now and
> > > then. In that case, things look pretty much like on 4.12.2. Here's
> > > a 4.15.0 fast resume example:
> > >
> > > [ 873.127570] usb 1-4: device firmware changed
> > > [ 873.277351] usb 1-8: reset high-speed USB device number 4 using xhci_hcd
> > > [ 873.515141] restoring control 00000000-0000-0000-0000-000000000101/0/2
> > > [ 873.583238] OOM killer enabled.
> > > [ 873.583240] Restarting tasks ...
> > > [ 873.583339] usb 1-4: USB disconnect, device number 10
> > > [ 873.586356] done.
> > > [ 873.604420] PM: suspend exit
> > > [ 873.737283] usb 1-4: new high-speed USB device number 11 using xhci_hcd
> > > [ 880.867398] usb 1-4: device descriptor read/64, error -110
> > > [ 881.175558] usb 1-4: New USB device found, idVendor=1199, idProduct=a001
> > > [ 881.175563] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > > [ 881.175566] usb 1-4: Product: Sierra Wireless EM7345 4G LTE
> > > [ 881.175568] usb 1-4: Manufacturer: Sierra Wireless Inc.
> > > [ 881.175570] usb 1-4: SerialNumber: 013937002544516
> > >
> > > Any guess what might be behind this?
> >
> > Any chance you can run 'git bisect' to find the offending commit for
> > this issue?
>
> It's 662591461c4b9a1e3b9b159dbf37648a585ebaae. To my eyes, it even
> looks plausible that it's causing the problematic behaviour, but
> since I can't say I understand what I'd be doing if I dabbled with
> the change, I've refrained from guessing how to fix it.
>
> I'm happy to try patches, though.
Ok, thanks. I've added the authors of this patch to the email here,
perhaps they have an idea of what is going on?
greg k-h
commit 9862b43624 upstream
There has been a race condition identified with initialization of the dell-laptop
driver due to changes in 4.15. This commit has been shown to resolve the race
condition.
I'd like to see this brought back to 4.15 stable. It doesn't apply to anything earlier.
Thanks,
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
Signed-off-by: Bin Liu <b-liu(a)ti.com>
---
drivers/usb/musb/musb_host.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 394b4ac86161..45ed32c2cba9 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -391,13 +391,7 @@ static void musb_advance_schedule(struct musb *musb, struct urb *urb,
}
}
- /*
- * 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);
--
1.9.1
The patch titled
Subject: mm, swap, frontswap: Fix THP swap if frontswap enabled
has been added to the -mm tree. Its filename is
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-frontswap-fix-thp-swap-if-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-swap-frontswap-fix-thp-swap-if-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Subject: mm, swap, frontswap: Fix THP swap if frontswap enabled
It was reported by Sergey Senozhatsky that if THP (Transparent Huge Page)
and frontswap (via zswap) are both enabled, when memory goes low so that
swap is triggered, segfault and memory corruption will occur in random
user space applications as follow,
kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
#0 0x00007fc08889ae0d _int_malloc (libc.so.6)
#1 0x00007fc08889c2f3 malloc (libc.so.6)
#2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
#3 0x0000560e6005e75c n/a (urxvt)
#4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
#5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
#6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
#7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
#8 0x0000560e6005cb55 ev_run (urxvt)
#9 0x0000560e6003b9b9 main (urxvt)
#10 0x00007fc08883af4a __libc_start_main (libc.so.6)
#11 0x0000560e6003f9da _start (urxvt)
After bisection, it was found the first bad commit is bd4c82c22c367e068
("mm, THP, swap: delay splitting THP after swapped out").
The root cause is as follows:
When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages instead
to improve the performance. But zswap (frontswap) will treat THP as
normal page, so only the head page is saved. After swapping in, tail
pages will not be restored to its original contents, so cause the memory
corruption in the applications.
This is fixed via splitting THP before writing the page to swap device if
frontswap is enabled. To deal with the situation where frontswap is
enabled at runtime, whether the page is THP is checked before using
frontswap during swapping out too.
Link: http://lkml.kernel.org/r/20180207070035.30302-1-ying.huang@intel.com
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Dan Streetman <ddstreet(a)ieee.org>
Cc: Seth Jennings <sjenning(a)redhat.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Shaohua Li <shli(a)kernel.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.14+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_io.c | 2 +-
mm/swapfile.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff -puN mm/page_io.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled mm/page_io.c
--- a/mm/page_io.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled
+++ a/mm/page_io.c
@@ -250,7 +250,7 @@ int swap_writepage(struct page *page, st
unlock_page(page);
goto out;
}
- if (frontswap_store(page) == 0) {
+ if (!PageTransHuge(page) && frontswap_store(page) == 0) {
set_page_writeback(page);
unlock_page(page);
end_page_writeback(page);
diff -puN mm/swapfile.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled mm/swapfile.c
--- a/mm/swapfile.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled
+++ a/mm/swapfile.c
@@ -934,6 +934,9 @@ int get_swap_pages(int n_goal, bool clus
/* Only single cluster request supported */
WARN_ON_ONCE(n_goal > 1 && cluster);
+ /* Frontswap doesn't support THP */
+ if (frontswap_enabled() && cluster)
+ goto noswap;
avail_pgs = atomic_long_read(&nr_swap_pages) / nr_pages;
if (avail_pgs <= 0)
_
Patches currently in -mm which might be from huang.ying.caritas(a)gmail.com are
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled.patch
fontswap-thp-fix.patch
This is a note to let you know that I've just added the patch titled
KEYS: encrypted: fix buffer overread in valid_master_desc()
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:
keys-encrypted-fix-buffer-overread-in-valid_master_desc.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 794b4bc292f5d31739d89c0202c54e7dc9bc3add Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 8 Jun 2017 14:48:18 +0100
Subject: KEYS: encrypted: fix buffer overread in valid_master_desc()
From: Eric Biggers <ebiggers(a)google.com>
commit 794b4bc292f5d31739d89c0202c54e7dc9bc3add upstream.
With the 'encrypted' key type it was possible for userspace to provide a
data blob ending with a master key description shorter than expected,
e.g. 'keyctl add encrypted desc "new x" @s'. When validating such a
master key description, validate_master_desc() could read beyond the end
of the buffer. Fix this by using strncmp() instead of memcmp(). [Also
clean up the code to deduplicate some logic.]
Cc: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Jin Qian <jinqian(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/keys/encrypted-keys/encrypted.c | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -141,23 +141,22 @@ static int valid_ecryptfs_desc(const cha
*/
static int valid_master_desc(const char *new_desc, const char *orig_desc)
{
- if (!memcmp(new_desc, KEY_TRUSTED_PREFIX, KEY_TRUSTED_PREFIX_LEN)) {
- if (strlen(new_desc) == KEY_TRUSTED_PREFIX_LEN)
- goto out;
- if (orig_desc)
- if (memcmp(new_desc, orig_desc, KEY_TRUSTED_PREFIX_LEN))
- goto out;
- } else if (!memcmp(new_desc, KEY_USER_PREFIX, KEY_USER_PREFIX_LEN)) {
- if (strlen(new_desc) == KEY_USER_PREFIX_LEN)
- goto out;
- if (orig_desc)
- if (memcmp(new_desc, orig_desc, KEY_USER_PREFIX_LEN))
- goto out;
- } else
- goto out;
+ int prefix_len;
+
+ if (!strncmp(new_desc, KEY_TRUSTED_PREFIX, KEY_TRUSTED_PREFIX_LEN))
+ prefix_len = KEY_TRUSTED_PREFIX_LEN;
+ else if (!strncmp(new_desc, KEY_USER_PREFIX, KEY_USER_PREFIX_LEN))
+ prefix_len = KEY_USER_PREFIX_LEN;
+ else
+ return -EINVAL;
+
+ if (!new_desc[prefix_len])
+ return -EINVAL;
+
+ if (orig_desc && strncmp(new_desc, orig_desc, prefix_len))
+ return -EINVAL;
+
return 0;
-out:
- return -EINVAL;
}
/*
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
This is a note to let you know that I've just added the patch titled
media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.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 5331aec1bf9c9da557668174e0a4bfcee39f1121 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 15:56:28 -0500
Subject: media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 5331aec1bf9c9da557668174e0a4bfcee39f1121 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/soc_camera/soc_scale_crop.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/soc_camera/soc_scale_crop.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/media/platform/soc_camera/soc_scale_crop.c
+++ b/drivers/media/platform/soc_camera/soc_scale_crop.c
@@ -418,3 +418,7 @@ void soc_camera_calc_client_output(struc
mf->height = soc_camera_shift_scale(rect->height, shift, scale_v);
}
EXPORT_SYMBOL(soc_camera_calc_client_output);
+
+MODULE_DESCRIPTION("soc-camera scaling-cropping functions");
+MODULE_AUTHOR("Guennadi Liakhovetski <kernel(a)pengutronix.de>");
+MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.9/media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.patch
queue-4.9/auxdisplay-img-ascii-lcd-add-missing-module_description-author-license.patch
queue-4.9/asoc-pcm512x-add-missing-module_description-author-license.patch
queue-4.9/pinctrl-pxa-pxa2xx-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
b43: Add missing MODULE_FIRMWARE()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
b43-add-missing-module_firmware.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3c89a72ad80c64bdbd5ff851ee9c328a191f7e01 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Thu, 4 May 2017 11:27:52 +0200
Subject: b43: Add missing MODULE_FIRMWARE()
From: Takashi Iwai <tiwai(a)suse.de>
commit 3c89a72ad80c64bdbd5ff851ee9c328a191f7e01 upstream.
Some firmware entries were forgotten to be added via MODULE_FIRMWARE(), which
may result in the non-functional state when the driver is loaded in initrd.
Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1037344
Fixes: 15be8e89cdd9 ("b43: add more bcma cores")
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/broadcom/b43/main.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -71,8 +71,18 @@ MODULE_FIRMWARE("b43/ucode11.fw");
MODULE_FIRMWARE("b43/ucode13.fw");
MODULE_FIRMWARE("b43/ucode14.fw");
MODULE_FIRMWARE("b43/ucode15.fw");
+MODULE_FIRMWARE("b43/ucode16_lp.fw");
MODULE_FIRMWARE("b43/ucode16_mimo.fw");
+MODULE_FIRMWARE("b43/ucode24_lcn.fw");
+MODULE_FIRMWARE("b43/ucode25_lcn.fw");
+MODULE_FIRMWARE("b43/ucode25_mimo.fw");
+MODULE_FIRMWARE("b43/ucode26_mimo.fw");
+MODULE_FIRMWARE("b43/ucode29_mimo.fw");
+MODULE_FIRMWARE("b43/ucode33_lcn40.fw");
+MODULE_FIRMWARE("b43/ucode30_mimo.fw");
MODULE_FIRMWARE("b43/ucode5.fw");
+MODULE_FIRMWARE("b43/ucode40.fw");
+MODULE_FIRMWARE("b43/ucode42.fw");
MODULE_FIRMWARE("b43/ucode9.fw");
static int modparam_bad_frames_preempt;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/b43-add-missing-module_firmware.patch
This is a note to let you know that I've just added the patch titled
media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.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 5331aec1bf9c9da557668174e0a4bfcee39f1121 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 15:56:28 -0500
Subject: media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 5331aec1bf9c9da557668174e0a4bfcee39f1121 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/soc_camera/soc_scale_crop.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/soc_camera/soc_scale_crop.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/media/platform/soc_camera/soc_scale_crop.c
+++ b/drivers/media/platform/soc_camera/soc_scale_crop.c
@@ -405,3 +405,7 @@ void soc_camera_calc_client_output(struc
mf->height = soc_camera_shift_scale(rect->height, shift, scale_v);
}
EXPORT_SYMBOL(soc_camera_calc_client_output);
+
+MODULE_DESCRIPTION("soc-camera scaling-cropping functions");
+MODULE_AUTHOR("Guennadi Liakhovetski <kernel(a)pengutronix.de>");
+MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.4/media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.patch
queue-4.4/asoc-pcm512x-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
KEYS: encrypted: fix buffer overread in valid_master_desc()
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:
keys-encrypted-fix-buffer-overread-in-valid_master_desc.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 794b4bc292f5d31739d89c0202c54e7dc9bc3add Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 8 Jun 2017 14:48:18 +0100
Subject: KEYS: encrypted: fix buffer overread in valid_master_desc()
From: Eric Biggers <ebiggers(a)google.com>
commit 794b4bc292f5d31739d89c0202c54e7dc9bc3add upstream.
With the 'encrypted' key type it was possible for userspace to provide a
data blob ending with a master key description shorter than expected,
e.g. 'keyctl add encrypted desc "new x" @s'. When validating such a
master key description, validate_master_desc() could read beyond the end
of the buffer. Fix this by using strncmp() instead of memcmp(). [Also
clean up the code to deduplicate some logic.]
Cc: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Jin Qian <jinqian(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/keys/encrypted-keys/encrypted.c | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -141,23 +141,22 @@ static int valid_ecryptfs_desc(const cha
*/
static int valid_master_desc(const char *new_desc, const char *orig_desc)
{
- if (!memcmp(new_desc, KEY_TRUSTED_PREFIX, KEY_TRUSTED_PREFIX_LEN)) {
- if (strlen(new_desc) == KEY_TRUSTED_PREFIX_LEN)
- goto out;
- if (orig_desc)
- if (memcmp(new_desc, orig_desc, KEY_TRUSTED_PREFIX_LEN))
- goto out;
- } else if (!memcmp(new_desc, KEY_USER_PREFIX, KEY_USER_PREFIX_LEN)) {
- if (strlen(new_desc) == KEY_USER_PREFIX_LEN)
- goto out;
- if (orig_desc)
- if (memcmp(new_desc, orig_desc, KEY_USER_PREFIX_LEN))
- goto out;
- } else
- goto out;
+ int prefix_len;
+
+ if (!strncmp(new_desc, KEY_TRUSTED_PREFIX, KEY_TRUSTED_PREFIX_LEN))
+ prefix_len = KEY_TRUSTED_PREFIX_LEN;
+ else if (!strncmp(new_desc, KEY_USER_PREFIX, KEY_USER_PREFIX_LEN))
+ prefix_len = KEY_USER_PREFIX_LEN;
+ else
+ return -EINVAL;
+
+ if (!new_desc[prefix_len])
+ return -EINVAL;
+
+ if (orig_desc && strncmp(new_desc, orig_desc, prefix_len))
+ return -EINVAL;
+
return 0;
-out:
- return -EINVAL;
}
/*
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.4/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
This is a note to let you know that I've just added the patch titled
media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.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 5331aec1bf9c9da557668174e0a4bfcee39f1121 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 15:56:28 -0500
Subject: media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 5331aec1bf9c9da557668174e0a4bfcee39f1121 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/soc_camera/soc_scale_crop.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/soc_camera/soc_scale_crop.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/media/platform/soc_camera/soc_scale_crop.c
+++ b/drivers/media/platform/soc_camera/soc_scale_crop.c
@@ -420,3 +420,7 @@ void soc_camera_calc_client_output(struc
mf->height = soc_camera_shift_scale(rect->height, shift, scale_v);
}
EXPORT_SYMBOL(soc_camera_calc_client_output);
+
+MODULE_DESCRIPTION("soc-camera scaling-cropping functions");
+MODULE_AUTHOR("Guennadi Liakhovetski <kernel(a)pengutronix.de>");
+MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.15/media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.patch
queue-4.15/media-mtk-vcodec-add-missing-module_license-description.patch
queue-4.15/media-tegra-cec-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
media: tegra-cec: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
media-tegra-cec-add-missing-module_description-author-license.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 20772c1a6f0e03d4231e2b539863987fa0c94e89 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 15:56:52 -0500
Subject: media: tegra-cec: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 20772c1a6f0e03d4231e2b539863987fa0c94e89 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/tegra-cec/tegra_cec.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/tegra-cec/tegra_cec.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/platform/tegra-cec/tegra_cec.c
+++ b/drivers/media/platform/tegra-cec/tegra_cec.c
@@ -493,3 +493,8 @@ static struct platform_driver tegra_cec_
};
module_platform_driver(tegra_cec_driver);
+
+MODULE_DESCRIPTION("Tegra HDMI CEC driver");
+MODULE_AUTHOR("NVIDIA CORPORATION");
+MODULE_AUTHOR("Cisco Systems, Inc. and/or its affiliates");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.15/media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.patch
queue-4.15/media-mtk-vcodec-add-missing-module_license-description.patch
queue-4.15/media-tegra-cec-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION
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:
media-mtk-vcodec-add-missing-module_license-description.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 ccbc1e3876d5476fc23429690a683294ef0f755b Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 02:47:54 -0500
Subject: media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION
From: Jesse Chan <jc(a)linux.com>
commit ccbc1e3876d5476fc23429690a683294ef0f755b upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/mtk-vcodec/mtk-vcodec-common.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION is also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
@@ -115,3 +115,6 @@ struct mtk_vcodec_ctx *mtk_vcodec_get_cu
return ctx;
}
EXPORT_SYMBOL(mtk_vcodec_get_curr_ctx);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Mediatek video codec driver");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.15/media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.patch
queue-4.15/media-mtk-vcodec-add-missing-module_license-description.patch
queue-4.15/media-tegra-cec-add-missing-module_description-author-license.patch
This is a note to let you know that I've just added the patch titled
gpio: uniphier: fix mismatch between license text and MODULE_LICENSE
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:
gpio-uniphier-fix-mismatch-between-license-text-and-module_license.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 13f9d59cef91a027bb338fc79b564fafa7680cd8 Mon Sep 17 00:00:00 2001
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Date: Thu, 23 Nov 2017 19:01:49 +0900
Subject: gpio: uniphier: fix mismatch between license text and MODULE_LICENSE
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
commit 13f9d59cef91a027bb338fc79b564fafa7680cd8 upstream.
The comment block of this file indicates GPL-2.0 "only", while the
MODULE_LICENSE is GPL-2.0 "or later", as include/linux/module.h
describes as follows:
"GPL" [GNU Public License v2 or later]
"GPL v2" [GNU Public License v2]
I am the author of this driver, and my intention is GPL-2.0 "only".
Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-uniphier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpio/gpio-uniphier.c
+++ b/drivers/gpio/gpio-uniphier.c
@@ -505,4 +505,4 @@ module_platform_driver(uniphier_gpio_dri
MODULE_AUTHOR("Masahiro Yamada <yamada.masahiro(a)socionext.com>");
MODULE_DESCRIPTION("UniPhier GPIO driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are
queue-4.15/gpio-uniphier-fix-mismatch-between-license-text-and-module_license.patch
This is a note to let you know that I've just added the patch titled
media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
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:
media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.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 5331aec1bf9c9da557668174e0a4bfcee39f1121 Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 15:56:28 -0500
Subject: media: soc_camera: soc_scale_crop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
From: Jesse Chan <jc(a)linux.com>
commit 5331aec1bf9c9da557668174e0a4bfcee39f1121 upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/soc_camera/soc_scale_crop.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/soc_camera/soc_scale_crop.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/media/platform/soc_camera/soc_scale_crop.c
+++ b/drivers/media/platform/soc_camera/soc_scale_crop.c
@@ -419,3 +419,7 @@ void soc_camera_calc_client_output(struc
mf->height = soc_camera_shift_scale(rect->height, shift, scale_v);
}
EXPORT_SYMBOL(soc_camera_calc_client_output);
+
+MODULE_DESCRIPTION("soc-camera scaling-cropping functions");
+MODULE_AUTHOR("Guennadi Liakhovetski <kernel(a)pengutronix.de>");
+MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.14/media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.patch
queue-4.14/media-mtk-vcodec-add-missing-module_license-description.patch
This is a note to let you know that I've just added the patch titled
media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION
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:
media-mtk-vcodec-add-missing-module_license-description.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 ccbc1e3876d5476fc23429690a683294ef0f755b Mon Sep 17 00:00:00 2001
From: Jesse Chan <jc(a)linux.com>
Date: Mon, 20 Nov 2017 02:47:54 -0500
Subject: media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION
From: Jesse Chan <jc(a)linux.com>
commit ccbc1e3876d5476fc23429690a683294ef0f755b upstream.
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/mtk-vcodec/mtk-vcodec-common.o
see include/linux/module.h for more information
This adds the license as "GPL v2", which matches the header of the file.
MODULE_DESCRIPTION is also added.
Signed-off-by: Jesse Chan <jc(a)linux.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
@@ -115,3 +115,6 @@ struct mtk_vcodec_ctx *mtk_vcodec_get_cu
return ctx;
}
EXPORT_SYMBOL(mtk_vcodec_get_curr_ctx);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Mediatek video codec driver");
Patches currently in stable-queue which might be from jc(a)linux.com are
queue-4.14/media-soc_camera-soc_scale_crop-add-missing-module_description-author-license.patch
queue-4.14/media-mtk-vcodec-add-missing-module_license-description.patch
This is a note to let you know that I've just added the patch titled
ARM: exynos_defconfig: Enable options to mount a rootfs via NFS
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:
arm-exynos_defconfig-enable-options-to-mount-a-rootfs-via-nfs.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 19f79ccf6d77409cd138bce8db206cdac7fd5ea7 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez(a)collabora.co.uk>
Date: Fri, 27 Mar 2015 01:50:16 +0900
Subject: ARM: exynos_defconfig: Enable options to mount a rootfs via NFS
From: Javier Martinez Canillas <javier.martinez(a)collabora.co.uk>
commit 19f79ccf6d77409cd138bce8db206cdac7fd5ea7 upstream.
This patch enables the options to mount a rootfs over NFS and also
support for automatic configuration of IP addresses during boot as
needed by NFS.
Signed-off-by: Javier Martinez Canillas <javier.martinez(a)collabora.co.uk>
Signed-off-by: Kukjin Kim <kgene(a)kernel.org>
Signed-off-by: Guillaume Tucker <guillaume.tucker(a)collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/configs/exynos_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -33,6 +33,10 @@ CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
CONFIG_RFKILL_REGULATOR=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
@@ -170,6 +174,8 @@ CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_CRAMFS=y
CONFIG_ROMFS_FS=y
+CONFIG_NFS_FS=y
+CONFIG_ROOT_NFS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
Patches currently in stable-queue which might be from javier.martinez(a)collabora.co.uk are
queue-3.18/arm-exynos_defconfig-enable-options-to-mount-a-rootfs-via-nfs.patch
This is a note to let you know that I've just added the patch titled
KEYS: encrypted: fix buffer overread in valid_master_desc()
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:
keys-encrypted-fix-buffer-overread-in-valid_master_desc.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 794b4bc292f5d31739d89c0202c54e7dc9bc3add Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 8 Jun 2017 14:48:18 +0100
Subject: KEYS: encrypted: fix buffer overread in valid_master_desc()
From: Eric Biggers <ebiggers(a)google.com>
commit 794b4bc292f5d31739d89c0202c54e7dc9bc3add upstream.
With the 'encrypted' key type it was possible for userspace to provide a
data blob ending with a master key description shorter than expected,
e.g. 'keyctl add encrypted desc "new x" @s'. When validating such a
master key description, validate_master_desc() could read beyond the end
of the buffer. Fix this by using strncmp() instead of memcmp(). [Also
clean up the code to deduplicate some logic.]
Cc: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Jin Qian <jinqian(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/keys/encrypted-keys/encrypted.c | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -141,23 +141,22 @@ static int valid_ecryptfs_desc(const cha
*/
static int valid_master_desc(const char *new_desc, const char *orig_desc)
{
- if (!memcmp(new_desc, KEY_TRUSTED_PREFIX, KEY_TRUSTED_PREFIX_LEN)) {
- if (strlen(new_desc) == KEY_TRUSTED_PREFIX_LEN)
- goto out;
- if (orig_desc)
- if (memcmp(new_desc, orig_desc, KEY_TRUSTED_PREFIX_LEN))
- goto out;
- } else if (!memcmp(new_desc, KEY_USER_PREFIX, KEY_USER_PREFIX_LEN)) {
- if (strlen(new_desc) == KEY_USER_PREFIX_LEN)
- goto out;
- if (orig_desc)
- if (memcmp(new_desc, orig_desc, KEY_USER_PREFIX_LEN))
- goto out;
- } else
- goto out;
+ int prefix_len;
+
+ if (!strncmp(new_desc, KEY_TRUSTED_PREFIX, KEY_TRUSTED_PREFIX_LEN))
+ prefix_len = KEY_TRUSTED_PREFIX_LEN;
+ else if (!strncmp(new_desc, KEY_USER_PREFIX, KEY_USER_PREFIX_LEN))
+ prefix_len = KEY_USER_PREFIX_LEN;
+ else
+ return -EINVAL;
+
+ if (!new_desc[prefix_len])
+ return -EINVAL;
+
+ if (orig_desc && strncmp(new_desc, orig_desc, prefix_len))
+ return -EINVAL;
+
return 0;
-out:
- return -EINVAL;
}
/*
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-3.18/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
This is a note to let you know that I've just added the patch titled
ARM: exynos_defconfig: Enable NFSv4 client
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:
arm-exynos_defconfig-enable-nfsv4-client.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 1c1fb9b0c89a2506e556114c813a606bc1508d49 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <k.kozlowski(a)samsung.com>
Date: Wed, 25 Nov 2015 13:09:43 +0900
Subject: ARM: exynos_defconfig: Enable NFSv4 client
From: Krzysztof Kozlowski <k.kozlowski(a)samsung.com>
commit 1c1fb9b0c89a2506e556114c813a606bc1508d49 upstream.
NFS client is already enabled (NFS_FS) and by default it enables clients
for version 2 and 3. Enable explicitly the version 4 client to utilize
the newer protocol.
The NFS client is especially useful for testing kernel in automated
environments (network boot with network file system).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski(a)samsung.com>
Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker(a)collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/configs/exynos_defconfig | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -175,6 +175,7 @@ CONFIG_TMPFS_POSIX_ACL=y
CONFIG_CRAMFS=y
CONFIG_ROMFS_FS=y
CONFIG_NFS_FS=y
+CONFIG_NFS_V4=y
CONFIG_ROOT_NFS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ASCII=y
Patches currently in stable-queue which might be from k.kozlowski(a)samsung.com are
queue-3.18/arm-exynos_defconfig-enable-nfsv4-client.patch
The patch titled
Subject: locking/qrwlock: include asm/byteorder.h as needed
has been removed from the -mm tree. Its filename was
locking-qrwlock-include-asm-byteorderh-as-needed.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Arnd Bergmann <arnd(a)arndb.de>
Subject: locking/qrwlock: include asm/byteorder.h as needed
Moving the qrwlock struct definition into a header file introduced a
subtle bug on all little-endian machines, where some files in some
configurations would see the fields in an incorrect order. This was found
by building with an LTO enabled compiler that warns every time we try to
link together files with incompatible data structures.
A second patch changes linux/kconfig.h to always define the symbols, but
this seems to be the root cause of most of the issues, so I'd suggest we
do both.
On a current linux-next kernel, I verified that this header is responsible
for all type mismatches as a result from the endianess confusion.
Link: http://lkml.kernel.org/r/20180202154104.1522809-1-arnd@arndb.de
Fixes: e0d02285f16e ("locking/qrwlock: Use 'struct qrwlock' instead of 'struct __qrwlock'")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Nicolas Pitre <nico(a)linaro.org>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Babu Moger <babu.moger(a)amd.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/asm-generic/qrwlock_types.h | 1 +
1 file changed, 1 insertion(+)
diff -puN include/asm-generic/qrwlock_types.h~locking-qrwlock-include-asm-byteorderh-as-needed include/asm-generic/qrwlock_types.h
--- a/include/asm-generic/qrwlock_types.h~locking-qrwlock-include-asm-byteorderh-as-needed
+++ a/include/asm-generic/qrwlock_types.h
@@ -3,6 +3,7 @@
#define __ASM_GENERIC_QRWLOCK_TYPES_H
#include <linux/types.h>
+#include <asm/byteorder.h>
#include <asm/spinlock_types.h>
/*
_
Patches currently in -mm which might be from arnd(a)arndb.de are
kbuild-always-define-endianess-in-kconfigh.patch
bugh-work-around-gcc-pr82365-in-bug.patch
The patch titled
Subject: pipe: fix off-by-one error when checking buffer limits
has been removed from the -mm tree. Its filename was
pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Eric Biggers <ebiggers(a)google.com>
Subject: pipe: fix off-by-one error when checking buffer limits
With pipe-user-pages-hard set to 'N', users were actually only allowed up
to 'N - 1' buffers; and likewise for pipe-user-pages-soft.
Fix this to allow up to 'N' buffers, as would be expected.
Link: http://lkml.kernel.org/r/20180111052902.14409-5-ebiggers3@gmail.com
Fixes: b0b91d18e2e9 ("pipe: fix limit checking in pipe_set_size()")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Acked-by: Willy Tarreau <w(a)1wt.eu>
Acked-by: Kees Cook <keescook(a)chromium.org>
Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org>
Cc: Michael Kerrisk <mtk.manpages(a)gmail.com>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/pipe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN fs/pipe.c~pipe-fix-off-by-one-error-when-checking-buffer-limits fs/pipe.c
--- a/fs/pipe.c~pipe-fix-off-by-one-error-when-checking-buffer-limits
+++ a/fs/pipe.c
@@ -605,12 +605,12 @@ static unsigned long account_pipe_buffer
static bool too_many_pipe_buffers_soft(unsigned long user_bufs)
{
- return pipe_user_pages_soft && user_bufs >= pipe_user_pages_soft;
+ return pipe_user_pages_soft && user_bufs > pipe_user_pages_soft;
}
static bool too_many_pipe_buffers_hard(unsigned long user_bufs)
{
- return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
+ return pipe_user_pages_hard && user_bufs > pipe_user_pages_hard;
}
static bool is_unprivileged_user(void)
_
Patches currently in -mm which might be from ebiggers(a)google.com are
The patch titled
Subject: pipe: actually allow root to exceed the pipe buffer limits
has been removed from the -mm tree. Its filename was
pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Eric Biggers <ebiggers(a)google.com>
Subject: pipe: actually allow root to exceed the pipe buffer limits
pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply
to unprivileged users, as documented in both Documentation/sysctl/fs.txt
and the pipe(7) man page.
However, the capabilities are actually only checked when increasing a
pipe's size using F_SETPIPE_SZ, not when creating a new pipe. Therefore,
if pipe-user-pages-hard has been set, the root user can run into it and be
unable to create pipes. Similarly, if pipe-user-pages-soft has been set,
the root user can run into it and have their pipes limited to 1 page each.
Fix this by allowing the privileged override in both cases.
Link: http://lkml.kernel.org/r/20180111052902.14409-4-ebiggers3@gmail.com
Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Acked-by: Kees Cook <keescook(a)chromium.org>
Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org>
Cc: Michael Kerrisk <mtk.manpages(a)gmail.com>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: Willy Tarreau <w(a)1wt.eu>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/pipe.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff -puN fs/pipe.c~pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits fs/pipe.c
--- a/fs/pipe.c~pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits
+++ a/fs/pipe.c
@@ -613,6 +613,11 @@ static bool too_many_pipe_buffers_hard(u
return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
}
+static bool is_unprivileged_user(void)
+{
+ return !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN);
+}
+
struct pipe_inode_info *alloc_pipe_info(void)
{
struct pipe_inode_info *pipe;
@@ -629,12 +634,12 @@ struct pipe_inode_info *alloc_pipe_info(
user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
- if (too_many_pipe_buffers_soft(user_bufs)) {
+ if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) {
user_bufs = account_pipe_buffers(user, pipe_bufs, 1);
pipe_bufs = 1;
}
- if (too_many_pipe_buffers_hard(user_bufs))
+ if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user())
goto out_revert_acct;
pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
@@ -1065,7 +1070,7 @@ static long pipe_set_size(struct pipe_in
if (nr_pages > pipe->buffers &&
(too_many_pipe_buffers_hard(user_bufs) ||
too_many_pipe_buffers_soft(user_bufs)) &&
- !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) {
+ is_unprivileged_user()) {
ret = -EPERM;
goto out_revert_acct;
}
_
Patches currently in -mm which might be from ebiggers(a)google.com are
The patch titled
Subject: kasan: rework Kconfig settings
has been removed from the -mm tree. Its filename was
kasan-rework-kconfig-settings.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Arnd Bergmann <arnd(a)arndb.de>
Subject: kasan: rework Kconfig settings
We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which can
easily cause an overflow of the kernel stack, e.g.
drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes
lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes
drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes
drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes
fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes
To reduce this risk, -fsanitize-address-use-after-scope is now split out
into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack frames
that are smaller than 2 kilobytes most of the time on x86_64. An earlier
version of this patch also prevented combining KASAN_EXTRA with
KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.
All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y and
CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can bring
back that default now. KASAN_EXTRA=y still causes lots of warnings but
now defaults to !COMPILE_TEST to disable it in allmodconfig, and it
remains disabled in all other defconfigs since it is a new option. I
arbitrarily raise the warning limit for KASAN_EXTRA to 3072 to reduce the
noise, but an allmodconfig kernel still has around 50 warnings on gcc-7.
I experimented a bit more with smaller stack frames and have another
follow-up series that reduces the warning limit for 64-bit architectures
to 1280 bytes (without CONFIG_KASAN).
With earlier versions of this patch series, I also had patches to address
the warnings we get with KASAN and/or KASAN_EXTRA, using a
"noinline_if_stackbloat" annotation. That annotation now got replaced
with a gcc-8 bugfix (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
older compilers, which means that KASAN_EXTRA is now just as bad as before
and will lead to an instant stack overflow in a few extreme cases.
This reverts parts of commit commit 3f181b4 ("lib/Kconfig.debug: disable
-Wframe-larger-than warnings with KASAN=y"). Two patches in linux-next
should be merged first to avoid introducing warnings in an allmodconfig
build:
3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN")
16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN")
Do we really need to backport this?
I think we do: without this patch, enabling KASAN will lead to
unavoidable kernel stack overflow in certain device drivers when built
with gcc-7 or higher on linux-4.10+ or any version that contains a
backport of commit c5caf21ab0cf8. Most people are probably still on
older compilers, but it will get worse over time as they upgrade their
distros.
The warnings we get on kernels older than this should all be for code
that uses dangerously large stack frames, though most of them do not
cause an actual stack overflow by themselves.The asan-stack option was
added in linux-4.0, and commit 3f181b4d8652 ("lib/Kconfig.debug:
disable -Wframe-larger-than warnings with KASAN=y") effectively turned
off the warning for allmodconfig kernels, so I would like to see this
fix backported to any kernels later than 4.0.
I have done dozens of fixes for individual functions with stack frames
larger than 2048 bytes with asan-stack, and I plan to make sure that
all those fixes make it into the stable kernels as well (most are
already there).
Part of the complication here is that asan-stack (from 4.0) was
originally assumed to always require much larger stacks, but that
turned out to be a combination of multiple gcc bugs that we have now
worked around and fixed, but sanitize-address-use-after-scope (from
v4.10) has a much higher inherent stack usage and also suffers from at
least three other problems that we have analyzed but not yet fixed
upstream, each of them makes the stack usage more severe than it should
be.
Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Andrey Konovalov <andreyknvl(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
lib/Kconfig.debug | 2 +-
lib/Kconfig.kasan | 11 +++++++++++
scripts/Makefile.kasan | 2 ++
3 files changed, 14 insertions(+), 1 deletion(-)
diff -puN lib/Kconfig.debug~kasan-rework-kconfig-settings lib/Kconfig.debug
--- a/lib/Kconfig.debug~kasan-rework-kconfig-settings
+++ a/lib/Kconfig.debug
@@ -217,7 +217,7 @@ config ENABLE_MUST_CHECK
config FRAME_WARN
int "Warn for stack frames larger than (needs gcc 4.4)"
range 0 8192
- default 0 if KASAN
+ default 3072 if KASAN_EXTRA
default 2048 if GCC_PLUGIN_LATENT_ENTROPY
default 1280 if (!64BIT && PARISC)
default 1024 if (!64BIT && !PARISC)
diff -puN lib/Kconfig.kasan~kasan-rework-kconfig-settings lib/Kconfig.kasan
--- a/lib/Kconfig.kasan~kasan-rework-kconfig-settings
+++ a/lib/Kconfig.kasan
@@ -20,6 +20,17 @@ config KASAN
Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB
(the resulting kernel does not boot).
+config KASAN_EXTRA
+ bool "KAsan: extra checks"
+ depends on KASAN && DEBUG_KERNEL && !COMPILE_TEST
+ help
+ This enables further checks in the kernel address sanitizer, for now
+ it only includes the address-use-after-scope check that can lead
+ to excessive kernel stack usage, frame size warnings and longer
+ compile time.
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 has more
+
+
choice
prompt "Instrumentation type"
depends on KASAN
diff -puN scripts/Makefile.kasan~kasan-rework-kconfig-settings scripts/Makefile.kasan
--- a/scripts/Makefile.kasan~kasan-rework-kconfig-settings
+++ a/scripts/Makefile.kasan
@@ -38,7 +38,9 @@ else
endif
+ifdef CONFIG_KASAN_EXTRA
CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
+endif
CFLAGS_KASAN_NOSANITIZE := -fno-builtin
_
Patches currently in -mm which might be from arnd(a)arndb.de are
kbuild-always-define-endianess-in-kconfigh.patch
bugh-work-around-gcc-pr82365-in-bug.patch
The patch titled
Subject: kernel/relay.c: revert "kernel/relay.c: fix potential memory leak"
has been removed from the -mm tree. Its filename was
revert-kernel-relayc-fix-potential-memory-leak.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Eric Biggers <ebiggers(a)google.com>
Subject: kernel/relay.c: revert "kernel/relay.c: fix potential memory leak"
This reverts ba62bafe942b159a6 ("kernel/relay.c: fix potential memory leak").
This commit introduced a double free bug, because 'chan' is already
freed by the line:
kref_put(&chan->kref, relay_destroy_channel);
This bug was found by syzkaller, using the BLKTRACESETUP ioctl.
Link: http://lkml.kernel.org/r/20180127004759.101823-1-ebiggers3@gmail.com
Fixes: ba62bafe942b ("kernel/relay.c: fix potential memory leak")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Zhouyi Zhou <yizhouzhou(a)ict.ac.cn>
Cc: Jens Axboe <axboe(a)kernel.dk>
Cc: <stable(a)vger.kernel.org> [4.7+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/relay.c | 1 -
1 file changed, 1 deletion(-)
diff -puN kernel/relay.c~revert-kernel-relayc-fix-potential-memory-leak kernel/relay.c
--- a/kernel/relay.c~revert-kernel-relayc-fix-potential-memory-leak
+++ a/kernel/relay.c
@@ -611,7 +611,6 @@ free_bufs:
kref_put(&chan->kref, relay_destroy_channel);
mutex_unlock(&relay_channels_mutex);
- kfree(chan);
return NULL;
}
EXPORT_SYMBOL_GPL(relay_open);
_
Patches currently in -mm which might be from ebiggers(a)google.com are
The patch titled
Subject: kernel/async.c: revert "async: simplify lowest_in_progress()"
has been removed from the -mm tree. Its filename was
revert-async-simplify-lowest_in_progress.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Subject: kernel/async.c: revert "async: simplify lowest_in_progress()"
This reverts 92266d6ef60c2381 ("async: simplify lowest_in_progress()"),
which was simply wrong: In the case where domain is NULL, we now use the
wrong offsetof() in the list_first_entry macro, so we don't actually fetch
the ->cookie value, but rather the eight bytes located sizeof(struct
list_head) further into the struct async_entry.
On 64 bit, that's the data member, while on 32 bit, that's a u64 built
from func and data in some order.
I think the bug happens to be harmless in practice: It obviously only
affects callers which pass a NULL domain, and AFAICT the only such caller
is
async_synchronize_full() ->
async_synchronize_full_domain(NULL) ->
async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
and the ASYNC_COOKIE_MAX means that in practice we end up waiting for the
async_global_pending list to be empty - but it would break if somebody
happened to pass (void*)-1 as the data element to async_schedule, and of
course also if somebody ever does a async_synchronize_cookie_domain(,
NULL) with a "finite" cookie value.
Maybe the "harmless in practice" means this isn't -stable material. But
I'm not completely confident my quick git grep'ing is enough, and there
might be affected code in one of the earlier kernels that has since been
removed, so I'll leave the decision to the stable guys.
Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk
Fixes: 92266d6ef60c "async: simplify lowest_in_progress()"
Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Acked-by: Tejun Heo <tj(a)kernel.org>
Cc: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: Adam Wallis <awallis(a)codeaurora.org>
Cc: Lai Jiangshan <laijs(a)cn.fujitsu.com>
Cc: <stable(a)vger.kernel.org> [3.10+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/async.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff -puN kernel/async.c~revert-async-simplify-lowest_in_progress kernel/async.c
--- a/kernel/async.c~revert-async-simplify-lowest_in_progress
+++ a/kernel/async.c
@@ -84,20 +84,24 @@ static atomic_t entry_count;
static async_cookie_t lowest_in_progress(struct async_domain *domain)
{
- struct list_head *pending;
+ struct async_entry *first = NULL;
async_cookie_t ret = ASYNC_COOKIE_MAX;
unsigned long flags;
spin_lock_irqsave(&async_lock, flags);
- if (domain)
- pending = &domain->pending;
- else
- pending = &async_global_pending;
+ if (domain) {
+ if (!list_empty(&domain->pending))
+ first = list_first_entry(&domain->pending,
+ struct async_entry, domain_list);
+ } else {
+ if (!list_empty(&async_global_pending))
+ first = list_first_entry(&async_global_pending,
+ struct async_entry, global_list);
+ }
- if (!list_empty(pending))
- ret = list_first_entry(pending, struct async_entry,
- domain_list)->cookie;
+ if (first)
+ ret = first->cookie;
spin_unlock_irqrestore(&async_lock, flags);
return ret;
_
Patches currently in -mm which might be from linux(a)rasmusvillemoes.dk are
ida-do-zeroing-in-ida_pre_get.patch
The patch titled
Subject: fs/proc/kcore.c: use probe_kernel_read() instead of memcpy()
has been removed from the -mm tree. Its filename was
fs-proc-kcorec-use-probe_kernel_read-instead-of-memcpy.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Subject: fs/proc/kcore.c: use probe_kernel_read() instead of memcpy()
df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data") added a
bounce buffer to avoid hardened usercopy checks. Copying to the bounce
buffer was implemented with a simple memcpy() assuming that it is always
valid to read from kernel memory iff the kern_addr_valid() check passed.
A simple, but pointless, test case like "dd if=/proc/kcore of=/dev/null"
now can easily crash the kernel, since the former execption handling on
invalid kernel addresses now doesn't work anymore.
Also adding a kern_addr_valid() implementation wouldn't help here. Most
architectures simply return 1 here, while a couple implemented a page
table walk to figure out if something is mapped at the address in
question.
With DEBUG_PAGEALLOC active mappings are established and removed all the
time, so that relying on the result of kern_addr_valid() before executing
the memcpy() also doesn't work.
Therefore simply use probe_kernel_read() to copy to the bounce buffer.
This also allows to simplify read_kcore().
At least on s390 this fixes the observed crashes and doesn't introduce
warnings that were removed with df04abfd181a ("fs/proc/kcore.c: Add bounce
buffer for ktext data"), even though the generic probe_kernel_read()
implementation uses uaccess functions.
While looking into this I'm also wondering if kern_addr_valid() could be
completely removed...(?)
Link: http://lkml.kernel.org/r/20171202132739.99971-1-heiko.carstens@de.ibm.com
Fixes: df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data")
Fixes: f5509cc18daa ("mm: Hardened usercopy")
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Acked-by: Kees Cook <keescook(a)chromium.org>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Al Viro <viro(a)ZenIV.linux.org.uk>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/proc/kcore.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff -puN fs/proc/kcore.c~fs-proc-kcorec-use-probe_kernel_read-instead-of-memcpy fs/proc/kcore.c
--- a/fs/proc/kcore.c~fs-proc-kcorec-use-probe_kernel_read-instead-of-memcpy
+++ a/fs/proc/kcore.c
@@ -512,23 +512,15 @@ read_kcore(struct file *file, char __use
return -EFAULT;
} else {
if (kern_addr_valid(start)) {
- unsigned long n;
-
/*
* Using bounce buffer to bypass the
* hardened user copy kernel text checks.
*/
- memcpy(buf, (char *) start, tsz);
- n = copy_to_user(buffer, buf, tsz);
- /*
- * We cannot distinguish between fault on source
- * and fault on destination. When this happens
- * we clear too and hope it will trigger the
- * EFAULT again.
- */
- if (n) {
- if (clear_user(buffer + tsz - n,
- n))
+ if (probe_kernel_read(buf, (void *) start, tsz)) {
+ if (clear_user(buffer, tsz))
+ return -EFAULT;
+ } else {
+ if (copy_to_user(buffer, buf, tsz))
return -EFAULT;
}
} else {
_
Patches currently in -mm which might be from heiko.carstens(a)de.ibm.com are
The patch titled
Subject: kasan: don't emit builtin calls when sanitization is off
has been removed from the -mm tree. Its filename was
kasan-dont-emit-builtin-calls-when-sanitization-is-off.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrey Konovalov <andreyknvl(a)google.com>
Subject: kasan: don't emit builtin calls when sanitization is off
With KASAN enabled the kernel has two different memset() functions, one
with KASAN checks (memset) and one without (__memset). KASAN uses some
macro tricks to use the proper version where required. For example
memset() calls in mm/slub.c are without KASAN checks, since they operate
on poisoned slab object metadata.
The issue is that clang emits memset() calls even when there is no
memset() in the source code. They get linked with improper memset()
implementation and the kernel fails to boot due to a huge amount of KASAN
reports during early boot stages.
The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
n marker.
Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.151638459…
Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com>
Acked-by: Nick Desaulniers <ndesaulniers(a)google.com>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: Michal Marek <michal.lkml(a)markovi.net>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
Makefile | 3 ++-
scripts/Makefile.kasan | 3 +++
scripts/Makefile.lib | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff -puN Makefile~kasan-dont-emit-builtin-calls-when-sanitization-is-off Makefile
--- a/Makefile~kasan-dont-emit-builtin-calls-when-sanitization-is-off
+++ a/Makefile
@@ -434,7 +434,8 @@ export MAKE LEX YACC AWK GENKSYMS INSTAL
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
+export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE CFLAGS_UBSAN
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
diff -puN scripts/Makefile.kasan~kasan-dont-emit-builtin-calls-when-sanitization-is-off scripts/Makefile.kasan
--- a/scripts/Makefile.kasan~kasan-dont-emit-builtin-calls-when-sanitization-is-off
+++ a/scripts/Makefile.kasan
@@ -31,4 +31,7 @@ else
endif
CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
+
+CFLAGS_KASAN_NOSANITIZE := -fno-builtin
+
endif
diff -puN scripts/Makefile.lib~kasan-dont-emit-builtin-calls-when-sanitization-is-off scripts/Makefile.lib
--- a/scripts/Makefile.lib~kasan-dont-emit-builtin-calls-when-sanitization-is-off
+++ a/scripts/Makefile.lib
@@ -121,7 +121,7 @@ endif
ifeq ($(CONFIG_KASAN),y)
_c_flags += $(if $(patsubst n%,, \
$(KASAN_SANITIZE_$(basetarget).o)$(KASAN_SANITIZE)y), \
- $(CFLAGS_KASAN))
+ $(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE))
endif
ifeq ($(CONFIG_UBSAN),y)
_
Patches currently in -mm which might be from andreyknvl(a)google.com are
This is a note to let you know that I've just added the patch titled
tcp: release sk_frag.page in tcp_disconnect
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:
tcp-release-sk_frag.page-in-tcp_disconnect.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 11:38:15 PST 2018
From: Li RongQing <lirongqing(a)baidu.com>
Date: Fri, 26 Jan 2018 16:40:41 +0800
Subject: tcp: release sk_frag.page in tcp_disconnect
From: Li RongQing <lirongqing(a)baidu.com>
[ Upstream commit 9b42d55a66d388e4dd5550107df051a9637564fc ]
socket can be disconnected and gets transformed back to a listening
socket, if sk_frag.page is not released, which will be cloned into
a new socket by sk_clone_lock, but the reference count of this page
is increased, lead to a use after free or double free issue
Signed-off-by: Li RongQing <lirongqing(a)baidu.com>
Cc: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/tcp.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2280,6 +2280,12 @@ int tcp_disconnect(struct sock *sk, int
WARN_ON(inet->inet_num && !icsk->icsk_bind_hash);
+ if (sk->sk_frag.page) {
+ put_page(sk->sk_frag.page);
+ sk->sk_frag.page = NULL;
+ sk->sk_frag.offset = 0;
+ }
+
sk->sk_error_report(sk);
return err;
}
Patches currently in stable-queue which might be from lirongqing(a)baidu.com are
queue-3.18/tcp-release-sk_frag.page-in-tcp_disconnect.patch
This is a note to let you know that I've just added the patch titled
r8169: fix RTL8168EP take too long to complete driver initialization.
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
r8169-fix-rtl8168ep-take-too-long-to-complete-driver-initialization.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 11:38:15 PST 2018
From: Chunhao Lin <hau(a)realtek.com>
Date: Wed, 31 Jan 2018 01:32:36 +0800
Subject: r8169: fix RTL8168EP take too long to complete driver initialization.
From: Chunhao Lin <hau(a)realtek.com>
[ Upstream commit 086ca23d03c0d2f4088f472386778d293e15c5f6 ]
Driver check the wrong register bit in rtl_ocp_tx_cond() that keep driver
waiting until timeout.
Fix this by waiting for the right register bit.
Signed-off-by: Chunhao Lin <hau(a)realtek.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/realtek/r8169.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1375,7 +1375,7 @@ DECLARE_RTL_COND(rtl_ocp_tx_cond)
{
void __iomem *ioaddr = tp->mmio_addr;
- return RTL_R8(IBISR0) & 0x02;
+ return RTL_R8(IBISR0) & 0x20;
}
static void rtl8168dp_driver_start(struct rtl8169_private *tp)
@@ -1421,7 +1421,7 @@ static void rtl8168ep_driver_stop(struct
void __iomem *ioaddr = tp->mmio_addr;
RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
- rtl_msleep_loop_wait_low(tp, &rtl_ocp_tx_cond, 50, 2000);
+ rtl_msleep_loop_wait_high(tp, &rtl_ocp_tx_cond, 50, 2000);
RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);
ocp_write(tp, 0x01, 0x180, OOB_CMD_DRIVER_STOP);
Patches currently in stable-queue which might be from hau(a)realtek.com are
queue-3.18/r8169-fix-rtl8168ep-take-too-long-to-complete-driver-initialization.patch
This is a note to let you know that I've just added the patch titled
net: igmp: add a missing rcu locking section
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-igmp-add-a-missing-rcu-locking-section.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 11:38:15 PST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Thu, 1 Feb 2018 10:26:57 -0800
Subject: net: igmp: add a missing rcu locking section
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit e7aadb27a5415e8125834b84a74477bfbee4eff5 ]
Newly added igmpv3_get_srcaddr() needs to be called under rcu lock.
Timer callbacks do not ensure this locking.
=============================
WARNING: suspicious RCU usage
4.15.0+ #200 Not tainted
-----------------------------
./include/linux/inetdevice.h:216 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by syzkaller616973/4074:
#0: (&mm->mmap_sem){++++}, at: [<00000000bfce669e>] __do_page_fault+0x32d/0xc90 arch/x86/mm/fault.c:1355
#1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] lockdep_copy_map include/linux/lockdep.h:178 [inline]
#1: ((&im->timer)){+.-.}, at: [<00000000619d2f71>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1316
#2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] spin_lock_bh include/linux/spinlock.h:315 [inline]
#2: (&(&im->lock)->rlock){+.-.}, at: [<000000005f833c5c>] igmpv3_send_report+0x98/0x5b0 net/ipv4/igmp.c:600
stack backtrace:
CPU: 0 PID: 4074 Comm: syzkaller616973 Not tainted 4.15.0+ #200
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592
__in_dev_get_rcu include/linux/inetdevice.h:216 [inline]
igmpv3_get_srcaddr net/ipv4/igmp.c:329 [inline]
igmpv3_newpack+0xeef/0x12e0 net/ipv4/igmp.c:389
add_grhead.isra.27+0x235/0x300 net/ipv4/igmp.c:432
add_grec+0xbd3/0x1170 net/ipv4/igmp.c:565
igmpv3_send_report+0xd5/0x5b0 net/ipv4/igmp.c:605
igmp_send_report+0xc43/0x1050 net/ipv4/igmp.c:722
igmp_timer_expire+0x322/0x5c0 net/ipv4/igmp.c:831
call_timer_fn+0x228/0x820 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x7ee/0xb70 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2d7/0xb85 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x1cc/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:541 [inline]
smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:938
Fixes: a46182b00290 ("net: igmp: Use correct source address on IGMPv3 reports")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/igmp.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -384,7 +384,11 @@ static struct sk_buff *igmpv3_newpack(st
pip->frag_off = htons(IP_DF);
pip->ttl = 1;
pip->daddr = fl4.daddr;
+
+ rcu_read_lock();
pip->saddr = igmpv3_get_srcaddr(dev, &fl4);
+ rcu_read_unlock();
+
pip->protocol = IPPROTO_IGMP;
pip->tot_len = 0; /* filled in later */
ip_select_ident(skb, NULL);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-3.18/tcp-release-sk_frag.page-in-tcp_disconnect.patch
queue-3.18/net-igmp-add-a-missing-rcu-locking-section.patch
This is a note to let you know that I've just added the patch titled
ip6mr: fix stale iterator
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:
ip6mr-fix-stale-iterator.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 11:38:15 PST 2018
From: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
Date: Wed, 31 Jan 2018 16:29:30 +0200
Subject: ip6mr: fix stale iterator
From: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
[ Upstream commit 4adfa79fc254efb7b0eb3cd58f62c2c3f805f1ba ]
When we dump the ip6mr mfc entries via proc, we initialize an iterator
with the table to dump but we don't clear the cache pointer which might
be initialized from a prior read on the same descriptor that ended. This
can result in lock imbalance (an unnecessary unlock) leading to other
crashes and hangs. Clear the cache pointer like ipmr does to fix the issue.
Thanks for the reliable reproducer.
Here's syzbot's trace:
WARNING: bad unlock balance detected!
4.15.0-rc3+ #128 Not tainted
syzkaller971460/3195 is trying to release lock (mrt_lock) at:
[<000000006898068d>] ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553
but there are no more locks to release!
other info that might help us debug this:
1 lock held by syzkaller971460/3195:
#0: (&p->lock){+.+.}, at: [<00000000744a6565>] seq_read+0xd5/0x13d0
fs/seq_file.c:165
stack backtrace:
CPU: 1 PID: 3195 Comm: syzkaller971460 Not tainted 4.15.0-rc3+ #128
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
print_unlock_imbalance_bug+0x12f/0x140 kernel/locking/lockdep.c:3561
__lock_release kernel/locking/lockdep.c:3775 [inline]
lock_release+0x5f9/0xda0 kernel/locking/lockdep.c:4023
__raw_read_unlock include/linux/rwlock_api_smp.h:225 [inline]
_raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255
ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553
traverse+0x3bc/0xa00 fs/seq_file.c:135
seq_read+0x96a/0x13d0 fs/seq_file.c:189
proc_reg_read+0xef/0x170 fs/proc/inode.c:217
do_loop_readv_writev fs/read_write.c:673 [inline]
do_iter_read+0x3db/0x5b0 fs/read_write.c:897
compat_readv+0x1bf/0x270 fs/read_write.c:1140
do_compat_preadv64+0xdc/0x100 fs/read_write.c:1189
C_SYSC_preadv fs/read_write.c:1209 [inline]
compat_SyS_preadv+0x3b/0x50 fs/read_write.c:1203
do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
RIP: 0023:0xf7f73c79
RSP: 002b:00000000e574a15c EFLAGS: 00000292 ORIG_RAX: 000000000000014d
RAX: ffffffffffffffda RBX: 000000000000000f RCX: 0000000020a3afb0
RDX: 0000000000000001 RSI: 0000000000000067 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
BUG: sleeping function called from invalid context at lib/usercopy.c:25
in_atomic(): 1, irqs_disabled(): 0, pid: 3195, name: syzkaller971460
INFO: lockdep is turned off.
CPU: 1 PID: 3195 Comm: syzkaller971460 Not tainted 4.15.0-rc3+ #128
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
___might_sleep+0x2b2/0x470 kernel/sched/core.c:6060
__might_sleep+0x95/0x190 kernel/sched/core.c:6013
__might_fault+0xab/0x1d0 mm/memory.c:4525
_copy_to_user+0x2c/0xc0 lib/usercopy.c:25
copy_to_user include/linux/uaccess.h:155 [inline]
seq_read+0xcb4/0x13d0 fs/seq_file.c:279
proc_reg_read+0xef/0x170 fs/proc/inode.c:217
do_loop_readv_writev fs/read_write.c:673 [inline]
do_iter_read+0x3db/0x5b0 fs/read_write.c:897
compat_readv+0x1bf/0x270 fs/read_write.c:1140
do_compat_preadv64+0xdc/0x100 fs/read_write.c:1189
C_SYSC_preadv fs/read_write.c:1209 [inline]
compat_SyS_preadv+0x3b/0x50 fs/read_write.c:1203
do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
RIP: 0023:0xf7f73c79
RSP: 002b:00000000e574a15c EFLAGS: 00000292 ORIG_RAX: 000000000000014d
RAX: ffffffffffffffda RBX: 000000000000000f RCX: 0000000020a3afb0
RDX: 0000000000000001 RSI: 0000000000000067 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
WARNING: CPU: 1 PID: 3195 at lib/usercopy.c:26 _copy_to_user+0xb5/0xc0
lib/usercopy.c:26
Reported-by: syzbot <bot+eceb3204562c41a438fa1f2335e0fe4f6886d669(a)syzkaller.appspotmail.com>
Signed-off-by: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6mr.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -498,6 +498,7 @@ static void *ipmr_mfc_seq_start(struct s
return ERR_PTR(-ENOENT);
it->mrt = mrt;
+ it->cache = NULL;
return *pos ? ipmr_mfc_seq_idx(net, seq->private, *pos - 1)
: SEQ_START_TOKEN;
}
Patches currently in stable-queue which might be from nikolay(a)cumulusnetworks.com are
queue-3.18/ip6mr-fix-stale-iterator.patch
This is a note to let you know that I've just added the patch titled
vhost_net: stop device during reset owner
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:
vhost_net-stop-device-during-reset-owner.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 11:22:35 PST 2018
From: Jason Wang <jasowang(a)redhat.com>
Date: Thu, 25 Jan 2018 22:03:52 +0800
Subject: vhost_net: stop device during reset owner
From: Jason Wang <jasowang(a)redhat.com>
[ Upstream commit 4cd879515d686849eec5f718aeac62a70b067d82 ]
We don't stop device before reset owner, this means we could try to
serve any virtqueue kick before reset dev->worker. This will result a
warn since the work was pending at llist during owner resetting. Fix
this by stopping device during owner reset.
Reported-by: syzbot+eb17c6162478cc50632c(a)syzkaller.appspotmail.com
Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server")
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/vhost/net.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -981,6 +981,7 @@ static long vhost_net_reset_owner(struct
}
vhost_net_stop(n, &tx_sock, &rx_sock);
vhost_net_flush(n);
+ vhost_dev_stop(&n->dev);
vhost_dev_reset_owner(&n->dev, memory);
vhost_net_vq_reset(n);
done:
Patches currently in stable-queue which might be from jasowang(a)redhat.com are
queue-4.4/vhost_net-stop-device-during-reset-owner.patch
This is a note to let you know that I've just added the patch titled
vhost_net: stop device during reset owner
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:
vhost_net-stop-device-during-reset-owner.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 11:22:35 PST 2018
From: Jason Wang <jasowang(a)redhat.com>
Date: Thu, 25 Jan 2018 22:03:52 +0800
Subject: vhost_net: stop device during reset owner
From: Jason Wang <jasowang(a)redhat.com>
[ Upstream commit 4cd879515d686849eec5f718aeac62a70b067d82 ]
We don't stop device before reset owner, this means we could try to
serve any virtqueue kick before reset dev->worker. This will result a
warn since the work was pending at llist during owner resetting. Fix
this by stopping device during owner reset.
Reported-by: syzbot+eb17c6162478cc50632c(a)syzkaller.appspotmail.com
Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server")
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/vhost/net.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1009,6 +1009,7 @@ static long vhost_net_reset_owner(struct
}
vhost_net_stop(n, &tx_sock, &rx_sock);
vhost_net_flush(n);
+ vhost_dev_stop(&n->dev);
vhost_dev_reset_owner(&n->dev, memory);
vhost_net_vq_reset(n);
done:
Patches currently in stable-queue which might be from jasowang(a)redhat.com are
queue-3.18/vhost_net-stop-device-during-reset-owner.patch
This is a note to let you know that I've just added the patch titled
r8169: fix RTL8168EP take too long to complete driver initialization.
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
r8169-fix-rtl8168ep-take-too-long-to-complete-driver-initialization.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 11:22:35 PST 2018
From: Chunhao Lin <hau(a)realtek.com>
Date: Wed, 31 Jan 2018 01:32:36 +0800
Subject: r8169: fix RTL8168EP take too long to complete driver initialization.
From: Chunhao Lin <hau(a)realtek.com>
[ Upstream commit 086ca23d03c0d2f4088f472386778d293e15c5f6 ]
Driver check the wrong register bit in rtl_ocp_tx_cond() that keep driver
waiting until timeout.
Fix this by waiting for the right register bit.
Signed-off-by: Chunhao Lin <hau(a)realtek.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/realtek/r8169.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1387,7 +1387,7 @@ DECLARE_RTL_COND(rtl_ocp_tx_cond)
{
void __iomem *ioaddr = tp->mmio_addr;
- return RTL_R8(IBISR0) & 0x02;
+ return RTL_R8(IBISR0) & 0x20;
}
static void rtl8168ep_stop_cmac(struct rtl8169_private *tp)
@@ -1395,7 +1395,7 @@ static void rtl8168ep_stop_cmac(struct r
void __iomem *ioaddr = tp->mmio_addr;
RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
- rtl_msleep_loop_wait_low(tp, &rtl_ocp_tx_cond, 50, 2000);
+ rtl_msleep_loop_wait_high(tp, &rtl_ocp_tx_cond, 50, 2000);
RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);
}
Patches currently in stable-queue which might be from hau(a)realtek.com are
queue-4.4/r8169-fix-rtl8168ep-take-too-long-to-complete-driver-initialization.patch
This is a note to let you know that I've just added the patch titled
tcp: release sk_frag.page in tcp_disconnect
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tcp-release-sk_frag.page-in-tcp_disconnect.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 7 11:22:35 PST 2018
From: Li RongQing <lirongqing(a)baidu.com>
Date: Fri, 26 Jan 2018 16:40:41 +0800
Subject: tcp: release sk_frag.page in tcp_disconnect
From: Li RongQing <lirongqing(a)baidu.com>
[ Upstream commit 9b42d55a66d388e4dd5550107df051a9637564fc ]
socket can be disconnected and gets transformed back to a listening
socket, if sk_frag.page is not released, which will be cloned into
a new socket by sk_clone_lock, but the reference count of this page
is increased, lead to a use after free or double free issue
Signed-off-by: Li RongQing <lirongqing(a)baidu.com>
Cc: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/tcp.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2276,6 +2276,12 @@ int tcp_disconnect(struct sock *sk, int
WARN_ON(inet->inet_num && !icsk->icsk_bind_hash);
+ if (sk->sk_frag.page) {
+ put_page(sk->sk_frag.page);
+ sk->sk_frag.page = NULL;
+ sk->sk_frag.offset = 0;
+ }
+
sk->sk_error_report(sk);
return err;
}
Patches currently in stable-queue which might be from lirongqing(a)baidu.com are
queue-4.4/tcp-release-sk_frag.page-in-tcp_disconnect.patch