From: Stephen Warren <swarren(a)nvidia.com>
[ Upstream commit 0cf253eed5d2bdf7bb3152457b38f39b012955f7 ]
The driver currently leaves GPIO IRQs unmasked even when the GPIO IRQ
client has released the GPIO IRQ. This allows the HW to raise IRQs, and
SW to process them, after shutdown. Fix this by masking the IRQ when it's
shut down. This is usually taken care of by the irqchip core, but since
this driver has a custom irq_shutdown implementation, it must do this
explicitly itself.
Signed-off-by: Stephen Warren <swarren(a)nvidia.com>
Link: https://lore.kernel.org/r/20200427232605.11608-1-swarren@wwwdotorg.org
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/gpio/gpio-tegra.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 05d3241ad20b..9d763557a105 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -341,6 +341,7 @@ static void tegra_gpio_irq_shutdown(struct irq_data *d)
struct tegra_gpio_info *tgi = bank->tgi;
int gpio = d->hwirq;
+ tegra_gpio_irq_mask(d);
gpiochip_unlock_as_irq(&tgi->gc, gpio);
}
--
2.25.1
From: Johan Jonker <jbx6244(a)gmail.com>
[ Upstream commit 287e0d538fcec2f6e8eb1e565bf0749f3b90186d ]
A test with the command below gives for example this error:
arch/arm/boot/dts/rk3228-evb.dt.yaml: phy@0:
'#phy-cells' is a required property
The phy nodename is normally used by a phy-handle.
This node is however compatible with
"ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22"
which is just been added to 'ethernet-phy.yaml'.
So change nodename to 'ethernet-phy' for which '#phy-cells'
is not a required property
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
phy/phy-provider.yaml
Signed-off-by: Johan Jonker <jbx6244(a)gmail.com>
Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
Link: https://lore.kernel.org/r/20200416170321.4216-1-jbx6244@gmail.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm/boot/dts/rk3228-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index 1be9daacc4f9..b69c842d8306 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -84,7 +84,7 @@
#address-cells = <1>;
#size-cells = <0>;
- phy: phy@0 {
+ phy: ethernet-phy@0 {
compatible = "ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22";
reg = <0>;
clocks = <&cru SCLK_MAC_PHY>;
--
2.25.1
From: Johan Jonker <jbx6244(a)gmail.com>
[ Upstream commit 287e0d538fcec2f6e8eb1e565bf0749f3b90186d ]
A test with the command below gives for example this error:
arch/arm/boot/dts/rk3228-evb.dt.yaml: phy@0:
'#phy-cells' is a required property
The phy nodename is normally used by a phy-handle.
This node is however compatible with
"ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22"
which is just been added to 'ethernet-phy.yaml'.
So change nodename to 'ethernet-phy' for which '#phy-cells'
is not a required property
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
phy/phy-provider.yaml
Signed-off-by: Johan Jonker <jbx6244(a)gmail.com>
Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
Link: https://lore.kernel.org/r/20200416170321.4216-1-jbx6244@gmail.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm/boot/dts/rk3228-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index 5670b33fd1bd..aed879db6c15 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -46,7 +46,7 @@
#address-cells = <1>;
#size-cells = <0>;
- phy: phy@0 {
+ phy: ethernet-phy@0 {
compatible = "ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22";
reg = <0>;
clocks = <&cru SCLK_MAC_PHY>;
--
2.25.1
On a modern Linux distro, compiling the following program fails:
#include<stdlib.h>
#include<stdint.h>
#include<pthread.h>
#include<linux/sched/types.h>
void main() {
struct sched_attr sa;
return;
}
with:
/usr/include/linux/sched/types.h:8:8: \
error: redefinition of ‘struct sched_param’
8 | struct sched_param {
| ^~~~~~~~~~~
In file included from /usr/include/x86_64-linux-gnu/bits/sched.h:74,
from /usr/include/sched.h:43,
from /usr/include/pthread.h:23,
from /tmp/s.c:4:
/usr/include/x86_64-linux-gnu/bits/types/struct_sched_param.h:23:8:
note: originally defined here
23 | struct sched_param
| ^~~~~~~~~~~
This is also causing a problem with using sched_attr in Chrome. The issue is
struct sched_param is already provided by glibc and is in POSIX.
Guard the kernel's UAPI definition of sched_param with __KERNEL__ so
that userspace and the kernel can both compile.
Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org>
---
v1->v2:
With the chance that libc needs resolving something, I'm resending with
libc-alpha added as suggested by Christian, and minor commit message fixes.
include/uapi/linux/sched/types.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/sched/types.h b/include/uapi/linux/sched/types.h
index c852153ddb0d3..1f10d935a63fe 100644
--- a/include/uapi/linux/sched/types.h
+++ b/include/uapi/linux/sched/types.h
@@ -4,9 +4,11 @@
#include <linux/types.h>
+#if defined(__KERNEL__)
struct sched_param {
int sched_priority;
};
+#endif
#define SCHED_ATTR_SIZE_VER0 48 /* sizeof first published struct */
#define SCHED_ATTR_SIZE_VER1 56 /* add: util_{min,max} */
--
2.26.2.761.g0e0b3e54be-goog
Hi Greg.
This is for 4.9.
This is a follow-up to "fix l2tp use-after-free in pppol2tp_sendmsg"
for 4.14. Pulling on the thread pulled in many other earlier locking
fixes in between 4.9 and 4.14.
I've done some minor rework on a few of these to avoid pulling in
refcount as a replacement for atomic which would have meant 10+ more
patches (I still had compilation errors at 10).
Some minor other patch commutation was needed and where it wasn't
completely trivial, I've added a note to the commit messages.
The series does include a few non-fixes, but they look safe and mean
that the fixes (and other backports) apply more cleanly.
Regards,
Giuliano.
Asbjørn Sloth Tønnesen (3):
net: l2tp: export debug flags to UAPI
net: l2tp: deprecate PPPOL2TP_MSG_* in favour of L2TP_MSG_*
net: l2tp: ppp: change PPPOL2TP_MSG_* => L2TP_MSG_*
Guillaume Nault (17):
l2tp: remove useless duplicate session detection in l2tp_netlink
l2tp: remove l2tp_session_find()
l2tp: define parameters of l2tp_session_get*() as "const"
l2tp: define parameters of l2tp_tunnel_find*() as "const"
l2tp: initialise session's refcount before making it reachable
l2tp: hold tunnel while looking up sessions in l2tp_netlink
l2tp: hold tunnel while processing genl delete command
l2tp: hold tunnel while handling genl tunnel updates
l2tp: hold tunnel while handling genl TUNNEL_GET commands
l2tp: hold tunnel used while creating sessions with netlink
l2tp: prevent creation of sessions on terminated tunnels
l2tp: pass tunnel pointer to ->session_create()
l2tp: fix l2tp_eth module loading
l2tp: don't register sessions in l2tp_session_create()
l2tp: initialise l2tp_eth sessions before registering them
l2tp: protect sock pointer of struct pppol2tp_session with RCU
l2tp: initialise PPP sessions before registering them
R. Parameswaran (2):
New kernel function to get IP overhead on a socket.
L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.
Documentation/networking/l2tp.txt | 8 +-
include/linux/net.h | 3 +
include/uapi/linux/if_pppol2tp.h | 13 +-
include/uapi/linux/l2tp.h | 17 +-
net/l2tp/l2tp_core.c | 174 ++++++-----------
net/l2tp/l2tp_core.h | 46 +++--
net/l2tp/l2tp_eth.c | 214 +++++++++++++--------
net/l2tp/l2tp_netlink.c | 79 ++++----
net/l2tp/l2tp_ppp.c | 309 ++++++++++++++++++------------
net/socket.c | 46 +++++
10 files changed, 516 insertions(+), 393 deletions(-)
--
2.26.2.761.g0e0b3e54be-goog
Hi Greg.
This is for 4.14.
We received a PoC (code to run as root with a KASAN kernel)
demonstrating the existence of a use-after-free in pppol2tp_sendmsg.
This was accompanied by a patch to resolve it, consisting mostly of
parts of patch 3 plus a little of 4.
The following patches all apply cleanly and compile with allmodconfig.
However, I lack the hardware to test them.
The changes are already in 4.19. I'll post the changes for 4.9 next.
Regards,
Giuliano.
Guillaume Nault (4):
l2tp: don't register sessions in l2tp_session_create()
l2tp: initialise l2tp_eth sessions before registering them
l2tp: protect sock pointer of struct pppol2tp_session with RCU
l2tp: initialise PPP sessions before registering them
net/l2tp/l2tp_core.c | 21 ++--
net/l2tp/l2tp_core.h | 3 +
net/l2tp/l2tp_eth.c | 99 +++++++++++++-----
net/l2tp/l2tp_ppp.c | 238 +++++++++++++++++++++++++++----------------
4 files changed, 238 insertions(+), 123 deletions(-)
--
2.26.2.761.g0e0b3e54be-goog
Please pick this fix for all stable branches:
commit 1413ef638abae4ab5621901cf4d8ef08a4a48ba6
Author: Kevin Hao <haokexin(a)gmail.com>
Date: Fri Oct 11 23:00:14 2019 +0800
i2c: dev: Fix the race between the release of i2c_dev and cdev
I don't know whether it will apply cleanly to all of them; I can deal
with those where it doesn't.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
This is a note to let you know that I've just added the patch titled
misc: rtsx: Add short delay after exit from ASPM
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7a839dbab1be59f5ed3b3b046de29e166784c9b4 Mon Sep 17 00:00:00 2001
From: Klaus Doth <kdlnx(a)doth.eu>
Date: Fri, 22 May 2020 12:56:04 +0200
Subject: misc: rtsx: Add short delay after exit from ASPM
DMA transfers to and from the SD card stall for 10 seconds and run into
timeout on RTS5260 card readers after ASPM was enabled.
Adding a short msleep after disabling ASPM fixes the issue on several
Dell Precision 7530/7540 systems I tested.
This function is only called when waking up after the chip went into
power-save after not transferring data for a few seconds. The added
msleep does therefore not change anything in data transfer speed or
induce any excessive waiting while data transfers are running, or the
chip is sleeping. Only the transition from sleep to active is affected.
Signed-off-by: Klaus Doth <kdlnx(a)doth.eu>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/4434eaa7-2ee3-a560-faee-6cee63ebd6d4@doth.eu
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/cardreader/rtsx_pcr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/misc/cardreader/rtsx_pcr.c b/drivers/misc/cardreader/rtsx_pcr.c
index 06038b325b02..55da6428ceb0 100644
--- a/drivers/misc/cardreader/rtsx_pcr.c
+++ b/drivers/misc/cardreader/rtsx_pcr.c
@@ -142,6 +142,9 @@ static void rtsx_comm_pm_full_on(struct rtsx_pcr *pcr)
rtsx_disable_aspm(pcr);
+ /* Fixes DMA transfer timout issue after disabling ASPM on RTS5260 */
+ msleep(1);
+
if (option->ltr_enabled)
rtsx_set_ltr_latency(pcr, option->ltr_active_latency);
--
2.26.2
I hope you are doing great?
This is Felix from Toronto-Canada. I have a lucrative business
offer that will benefit us both immensely within a very short
period of time. However, I need your initial approval of interest
prior to further and complete details regarding the deal.
Thanks,
Felix.
From: Eric Biggers <ebiggers(a)google.com>
'igrab(d_inode(dentry->d_parent))' without holding dentry->d_lock is
broken because without d_lock, d_parent can be concurrently changed due
to a rename(). Then if the old directory is immediately deleted, old
d_parent->inode can be NULL. That causes a NULL dereference in igrab().
To fix this, use dget_parent() to safely grab a reference to the parent
dentry, which pins the inode. This also eliminates the need to use
d_find_any_alias() other than for the initial inode, as we no longer
throw away the dentry at each step.
This is an extremely hard race to hit, but it is possible. Adding a
udelay() in between the reads of ->d_parent and its ->d_inode makes it
reproducible on a no-journal filesystem using the following program:
#include <fcntl.h>
#include <unistd.h>
int main()
{
if (fork()) {
for (;;) {
mkdir("dir1", 0700);
int fd = open("dir1/file", O_RDWR|O_CREAT|O_SYNC);
write(fd, "X", 1);
close(fd);
}
} else {
mkdir("dir2", 0700);
for (;;) {
rename("dir1/file", "dir2/file");
rmdir("dir1");
}
}
}
Fixes: d59729f4e794 ("ext4: fix races in ext4_sync_parent()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
fs/ext4/fsync.c | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/fs/ext4/fsync.c b/fs/ext4/fsync.c
index e10206e7f4bbe7..093c359952cdba 100644
--- a/fs/ext4/fsync.c
+++ b/fs/ext4/fsync.c
@@ -44,30 +44,28 @@
*/
static int ext4_sync_parent(struct inode *inode)
{
- struct dentry *dentry = NULL;
- struct inode *next;
+ struct dentry *dentry, *next;
int ret = 0;
if (!ext4_test_inode_state(inode, EXT4_STATE_NEWENTRY))
return 0;
- inode = igrab(inode);
+ dentry = d_find_any_alias(inode);
+ if (!dentry)
+ return 0;
while (ext4_test_inode_state(inode, EXT4_STATE_NEWENTRY)) {
ext4_clear_inode_state(inode, EXT4_STATE_NEWENTRY);
- dentry = d_find_any_alias(inode);
- if (!dentry)
- break;
- next = igrab(d_inode(dentry->d_parent));
+
+ next = dget_parent(dentry);
dput(dentry);
- if (!next)
- break;
- iput(inode);
- inode = next;
+ dentry = next;
+ inode = dentry->d_inode;
+
/*
* The directory inode may have gone through rmdir by now. But
* the inode itself and its blocks are still allocated (we hold
- * a reference to the inode so it didn't go through
- * ext4_evict_inode()) and so we are safe to flush metadata
- * blocks and the inode.
+ * a reference to the inode via its dentry), so it didn't go
+ * through ext4_evict_inode()) and so we are safe to flush
+ * metadata blocks and the inode.
*/
ret = sync_mapping_buffers(inode->i_mapping);
if (ret)
@@ -76,7 +74,7 @@ static int ext4_sync_parent(struct inode *inode)
if (ret)
break;
}
- iput(inode);
+ dput(dentry);
return ret;
}
--
2.26.2
From: Mathias Krause <minipli(a)googlemail.com>
[ Upstream commit 1bd845bcb41d5b7f83745e0cb99273eb376f2ec5 ]
The parallel queue per-cpu data structure gets initialized only for CPUs
in the 'pcpu' CPU mask set. This is not sufficient as the reorder timer
may run on a different CPU and might wrongly decide it's the target CPU
for the next reorder item as per-cpu memory gets memset(0) and we might
be waiting for the first CPU in cpumask.pcpu, i.e. cpu_index 0.
Make the '__this_cpu_read(pd->pqueue->cpu_index) == next_queue->cpu_index'
compare in padata_get_next() fail in this case by initializing the
cpu_index member of all per-cpu parallel queues. Use -1 for unused ones.
Signed-off-by: Mathias Krause <minipli(a)googlemail.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Daniel Jordan <daniel.m.jordan(a)oracle.com>
---
kernel/padata.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 8aef48c3267b..4f860043a8e5 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -461,8 +461,14 @@ static void padata_init_pqueues(struct parallel_data *pd)
struct padata_parallel_queue *pqueue;
cpu_index = 0;
- for_each_cpu(cpu, pd->cpumask.pcpu) {
+ for_each_possible_cpu(cpu) {
pqueue = per_cpu_ptr(pd->pqueue, cpu);
+
+ if (!cpumask_test_cpu(cpu, pd->cpumask.pcpu)) {
+ pqueue->cpu_index = -1;
+ continue;
+ }
+
pqueue->pd = pd;
pqueue->cpu_index = cpu_index;
cpu_index++;
--
2.26.2
Changes since v2 [1]:
- Replace the non-descriptive copy_safe() with copy_mc_to_user() and
copy_mc_to_kernel() several code organization cleanups resulted from
this rename, which further proves the point that the name deeply
matters for maintainability in this case. (Linus)
- Do not use copy_user_generic() as the generic x86 backend for
copy_mc_to_user() since the #MC handler explicitly wants the exception
to be trapped by a _ASM_EXTABLE_FAULT handler. (Vivek).
- Rename copy_safe_slow() to copy_mc_fragile() to better indicate what
the implementation is handling. copy_safe_fast() is replaced with
copy_mc_generic().
---
The primary motivation to go touch memcpy_mcsafe() is that the existing
benefit of doing slow "handle with care" copies is obviated on newer
CPUs. With that concern lifted it also obviates the need to continue to
update the MCA-recovery capability detection code currently gated by
"mcsafe_key". Now the old "mcsafe_key" opt-in to perform the copy with
concerns for recovery fragility can instead be made an opt-out from the
default fast copy implementation (enable_copy_mc_fragile()).
The discussion with Linus on the first iteration of this patch
identified that memcpy_mcsafe() was misnamed relative to its usage. The
new names copy_mc_to_user() and copy_mc_to_kernel() clearly indicate the
intended use case and lets the architecture organize the implementation
accordingly.
For both powerpc and x86 a copy_mc_generic() implementation is added as
the backend for these interfaces.
Patches are relative to tip/master.
---
Dan Williams (2):
x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user,kernel}()
x86/copy_mc: Introduce copy_mc_generic()
arch/powerpc/Kconfig | 2
arch/powerpc/include/asm/string.h | 2
arch/powerpc/include/asm/uaccess.h | 40 +++--
arch/powerpc/lib/Makefile | 2
arch/powerpc/lib/copy_mc_64.S | 4
arch/x86/Kconfig | 2
arch/x86/Kconfig.debug | 2
arch/x86/include/asm/copy_mc_test.h | 75 +++++++++
arch/x86/include/asm/mcsafe_test.h | 75 ---------
arch/x86/include/asm/string_64.h | 32 ----
arch/x86/include/asm/uaccess_64.h | 35 ++--
arch/x86/kernel/cpu/mce/core.c | 8 -
arch/x86/kernel/quirks.c | 9 -
arch/x86/lib/Makefile | 1
arch/x86/lib/copy_mc.c | 64 ++++++++
arch/x86/lib/copy_mc_64.S | 165 ++++++++++++++++++++
arch/x86/lib/memcpy_64.S | 115 --------------
arch/x86/lib/usercopy_64.c | 21 ---
drivers/md/dm-writecache.c | 15 +-
drivers/nvdimm/claim.c | 2
drivers/nvdimm/pmem.c | 6 -
include/linux/string.h | 9 -
include/linux/uaccess.h | 9 +
include/linux/uio.h | 10 +
lib/Kconfig | 7 +
lib/iov_iter.c | 43 +++--
tools/arch/x86/include/asm/copy_safe_test.h | 13 ++
tools/arch/x86/include/asm/mcsafe_test.h | 13 --
tools/arch/x86/lib/memcpy_64.S | 115 --------------
tools/objtool/check.c | 5 -
tools/perf/bench/Build | 1
tools/perf/bench/mem-memcpy-x86-64-lib.c | 24 ---
tools/testing/nvdimm/test/nfit.c | 48 +++---
.../testing/selftests/powerpc/copyloops/.gitignore | 2
tools/testing/selftests/powerpc/copyloops/Makefile | 6 -
.../testing/selftests/powerpc/copyloops/copy_mc.S | 0
36 files changed, 460 insertions(+), 522 deletions(-)
rename arch/powerpc/lib/{memcpy_mcsafe_64.S => copy_mc_64.S} (98%)
create mode 100644 arch/x86/include/asm/copy_mc_test.h
delete mode 100644 arch/x86/include/asm/mcsafe_test.h
create mode 100644 arch/x86/lib/copy_mc.c
create mode 100644 arch/x86/lib/copy_mc_64.S
create mode 100644 tools/arch/x86/include/asm/copy_safe_test.h
delete mode 100644 tools/arch/x86/include/asm/mcsafe_test.h
delete mode 100644 tools/perf/bench/mem-memcpy-x86-64-lib.c
rename tools/testing/selftests/powerpc/copyloops/{memcpy_mcsafe_64.S => copy_mc.S} (100%)
base-commit: bba413deb1065f1291cb1f366247513f11215520
When reserved transaction handle is unused, we subtract its reserved
credits in __jbd2_journal_unreserve_handle() called from
jbd2_journal_stop(). However this function forgets to remove reserved
credits from transaction->t_outstanding_credits and thus the transaction
space that was reserved remains effectively leaked. The leaked
transaction space can be quite significant in some cases and leads to
unnecessarily small transactions and thus reducing throughput of the
journalling machinery. E.g. fsmark workload creating lots of 4k files
was observed to have about 20% lower throughput due to this when ext4 is
mounted with dioread_nolock mount option.
Subtract reserved credits from t_outstanding_credits as well.
CC: stable(a)vger.kernel.org
Fixes: 8f7d89f36829 ("jbd2: transaction reservation support")
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/jbd2/transaction.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index 3dccc23cf010..b49a103cff1f 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -541,17 +541,24 @@ handle_t *jbd2_journal_start(journal_t *journal, int nblocks)
}
EXPORT_SYMBOL(jbd2_journal_start);
-static void __jbd2_journal_unreserve_handle(handle_t *handle)
+static void __jbd2_journal_unreserve_handle(handle_t *handle, transaction_t *t)
{
journal_t *journal = handle->h_journal;
WARN_ON(!handle->h_reserved);
sub_reserved_credits(journal, handle->h_total_credits);
+ if (t)
+ atomic_sub(handle->h_total_credits, &t->t_outstanding_credits);
}
void jbd2_journal_free_reserved(handle_t *handle)
{
- __jbd2_journal_unreserve_handle(handle);
+ journal_t *journal = handle->h_journal;
+
+ /* Get j_state_lock to pin running transaction if it exists */
+ read_lock(&journal->j_state_lock);
+ __jbd2_journal_unreserve_handle(handle, journal->j_running_transaction);
+ read_unlock(&journal->j_state_lock);
jbd2_free_handle(handle);
}
EXPORT_SYMBOL(jbd2_journal_free_reserved);
@@ -721,8 +728,10 @@ static void stop_this_handle(handle_t *handle)
}
atomic_sub(handle->h_total_credits,
&transaction->t_outstanding_credits);
- if (handle->h_rsv_handle)
- __jbd2_journal_unreserve_handle(handle->h_rsv_handle);
+ if (handle->h_rsv_handle) {
+ __jbd2_journal_unreserve_handle(handle->h_rsv_handle,
+ transaction);
+ }
if (atomic_dec_and_test(&transaction->t_updates))
wake_up(&journal->j_wait_updates);
--
2.16.4
When using mmap() on a prime imported buffer allocated by a
different driver (such as imx-drm) the later munmap() does
not correctly decrement the refcount of the original enaviv_gem_object,
leading to a leak.
Signed-off-by: Martin Fuzzey <martin.fuzzey(a)flowbird.group>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index f24dd21..28a01b8 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -93,7 +93,25 @@ static void *etnaviv_gem_prime_vmap_impl(struct etnaviv_gem_object *etnaviv_obj)
static int etnaviv_gem_prime_mmap_obj(struct etnaviv_gem_object *etnaviv_obj,
struct vm_area_struct *vma)
{
- return dma_buf_mmap(etnaviv_obj->base.dma_buf, vma, 0);
+ int ret;
+
+ ret = dma_buf_mmap(etnaviv_obj->base.dma_buf, vma, 0);
+
+ /* drm_gem_mmap_obj() has already been called before this function
+ * and has incremented our refcount, expecting it to be decremented
+ * on unmap() via drm_gem_vm_close().
+ * However dma_buf_mmap() invokes drm_gem_cma_prime_mmap()
+ * that ends up updating the vma->vma_private_data to point to the
+ * dma_buf's gem object.
+ * Hence our gem object here will not have its refcount decremented
+ * when userspace does unmap().
+ * So decrement the refcount here to avoid a memory leak if the dma
+ * buf mapping was successful.
+ */
+ if (!ret)
+ drm_gem_object_put_unlocked(&etnaviv_obj->base);
+
+ return ret;
}
static const struct etnaviv_gem_ops etnaviv_gem_prime_ops = {
--
1.9.1
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: 4.4+
The bot has tested the following trees: v5.6.13, v5.4.41, v4.19.123, v4.14.180, v4.9.223, v4.4.223.
v5.6.13: Failed to apply! Possible dependencies:
0024652895e3 ("btrfs: rename btrfs_put_fs_root and btrfs_grab_fs_root")
02162a0265eb ("btrfs: hold a ref on the root in __btrfs_run_defrag_inode")
04734e844894 ("btrfs: hold a ref on the root in btrfs_ioctl_get_subvol_info")
0b530bc5e11f ("btrfs: hold a ref on the root in build_backref_tree")
0d4b0463011d ("btrfs: export and rename free_fs_info")
2a2b5d620266 ("btrfs: hold ref on root in btrfs_ioctl_default_subvol")
3ca35e839e94 ("btrfs: hold a ref on the root in search_ioctl")
3d7babdcf2cc ("btrfs: hold a ref on the root in find_data_references")
41a2ee75aab0 ("btrfs: introduce per-inode file extent tree")
442b1ac5244e ("btrfs: hold a ref on the root in record_reloc_root_in_trans")
4c78e9f59632 ("btrfs: hold a ref on the root in open_ctree")
76deacf02387 ("btrfs: hold a ref on the root in create_reloc_inode")
81f096edf047 ("btrfs: use btrfs_put_fs_root to free roots always")
8727002f7909 ("btrfs: hold a ref on the root in fixup_tree_root_location")
88234012beaa ("btrfs: hold a ref on the root in btrfs_search_path_in_tree")
9326f76f4bc4 ("btrfs: hold a ref on the root in resolve_indirect_ref")
9f583209f20a ("btrfs: push grab_fs_root into read_fs_root")
ab9737bd7597 ("btrfs: hold a ref on the root in merge_reloc_roots")
b8a49ae1913f ("btrfs: hold a ref on the root in btrfs_search_path_in_tree_user")
bc44d7c4b2b1 ("btrfs: push btrfs_grab_fs_root into btrfs_get_fs_root")
bdf70b9e75f5 ("btrfs: hold a root ref in btrfs_get_dentry")
db2c2ca2db44 ("btrfs: hold a ref on the root in prepare_to_merge")
fc92f79856aa ("btrfs: hold a ref on the root in create_subvol")
v5.4.41: Failed to apply! Possible dependencies:
0024652895e3 ("btrfs: rename btrfs_put_fs_root and btrfs_grab_fs_root")
0d4b0463011d ("btrfs: export and rename free_fs_info")
33ca832fefa5 ("btrfs: separate out the extent leak code")
41a2ee75aab0 ("btrfs: introduce per-inode file extent tree")
6f0d04f8e72e ("btrfs: separate out the extent io init function")
81f096edf047 ("btrfs: use btrfs_put_fs_root to free roots always")
9326f76f4bc4 ("btrfs: hold a ref on the root in resolve_indirect_ref")
9c7d3a548331 ("btrfs: move extent_io_tree defs to their own header")
v4.19.123: Failed to apply! Possible dependencies:
370a11b8114b ("btrfs: qgroup: Introduce per-root swapped blocks infrastructure")
43eb5f297584 ("btrfs: Introduce extent_io_tree::owner to distinguish different io_trees")
57ec5fb478a3 ("btrfs: tests: move testing members of struct btrfs_root to the end")
7b4397386fbd ("btrfs: switch extent_io_tree::track_uptodate to bool")
c258d6e36442 ("btrfs: Introduce fs_info to extent_io_tree")
e06a1fc99cc7 ("btrfs: Remove extent_io_ops::set_bit_hook extent_io callback")
eede2bf34f4f ("Btrfs: prevent ioctls from interfering with a swap file")
v4.14.180: Failed to apply! Possible dependencies:
370a11b8114b ("btrfs: qgroup: Introduce per-root swapped blocks infrastructure")
429d6275d501 ("btrfs: qgroup: Fix wrong qgroup reservation update for relationship modification")
57ec5fb478a3 ("btrfs: tests: move testing members of struct btrfs_root to the end")
64cfaef6362f ("btrfs: qgroup: Introduce function to convert META_PREALLOC into META_PERTRANS")
64ee4e751a1c ("btrfs: qgroup: Update trace events to use new separate rsv types")
733e03a0b26a ("btrfs: qgroup: Split meta rsv type into meta_prealloc and meta_pertrans")
8287475a2055 ("btrfs: qgroup: Use root::qgroup_meta_rsv_* to record qgroup meta reserved space")
d4e5c92055d8 ("btrfs: qgroup: Skeleton to support separate qgroup reservation type")
dba213242fbc ("btrfs: qgroup: Make qgroup_reserve and its callers to use separate reservation type")
e1211d0e896b ("btrfs: qgroup: Don't use root->qgroup_meta_rsv for qgroup")
eede2bf34f4f ("Btrfs: prevent ioctls from interfering with a swap file")
f59c0347d4be ("btrfs: qgroup: Introduce helpers to update and access new qgroup rsv")
fd708b81d972 ("Btrfs: add a extent ref verify tool")
v4.9.223: Failed to apply! Possible dependencies:
0c476a5d7f63 ("btrfs: Ensure proper sector alignment for btrfs_free_reserved_data_space")
370a11b8114b ("btrfs: qgroup: Introduce per-root swapped blocks infrastructure")
4989d277eb4b ("btrfs: refactor __btrfs_lookup_bio_sums to use bio_for_each_segment_all")
62d1f9fe97dd ("btrfs: remove trivial helper btrfs_find_tree_block")
da17066c4047 ("btrfs: pull node/sector/stripe sizes out of root and into fs_info")
eede2bf34f4f ("Btrfs: prevent ioctls from interfering with a swap file")
fd708b81d972 ("Btrfs: add a extent ref verify tool")
v4.4.223: Failed to apply! Possible dependencies:
2f3165ecf103 ("btrfs: don't force mounts to wait for cleaner_kthread to delete one or more subvolumes")
370a11b8114b ("btrfs: qgroup: Introduce per-root swapped blocks infrastructure")
511711af91f2 ("btrfs: don't run delayed references while we are creating the free space tree")
70f6d82ec73c ("Btrfs: add free space tree mount option")
87241c2e6845 ("Btrfs: use root when checking need_async_flush")
90c711ab380d ("btrfs: avoid blocking open_ctree from cleaner_kthread")
9e7cc91a6d18 ("btrfs: fix fsfreeze hang caused by delayed iputs deal")
a5ed91828518 ("Btrfs: implement the free space B-tree")
afcdd129e05a ("Btrfs: add a flags field to btrfs_fs_info")
d38b349c39a9 ("Btrfs: don't bother kicking async if there's nothing to reclaim")
eede2bf34f4f ("Btrfs: prevent ioctls from interfering with a swap file")
f376df2b7da3 ("Btrfs: add tracepoints for flush events")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
From: Herbert Xu <herbert(a)gondor.apana.org.au>
[ Upstream commit 6fc4dbcf0276279d488c5fbbfabe94734134f4fa ]
The function padata_reorder will use a timer when it cannot progress
while completed jobs are outstanding (pd->reorder_objects > 0). This
is suboptimal as if we do end up using the timer then it would have
introduced a gratuitous delay of one second.
In fact we can easily distinguish between whether completed jobs
are outstanding and whether we can make progress. All we have to
do is look at the next pqueue list.
This patch does that by replacing pd->processed with pd->cpu so
that the next pqueue is more accessible.
A work queue is used instead of the original try_again to avoid
hogging the CPU.
Note that we don't bother removing the work queue in
padata_flush_queues because the whole premise is broken. You
cannot flush async crypto requests so it makes no sense to even
try. A subsequent patch will fix it by replacing it with a ref
counting scheme.
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
[dj: - adjust context
- corrected setup_timer -> timer_setup to delete hunk
- skip padata_flush_queues() hunk, function already removed
in 4.19]
Signed-off-by: Daniel Jordan <daniel.m.jordan(a)oracle.com>
---
include/linux/padata.h | 13 ++----
kernel/padata.c | 95 ++++++++----------------------------------
2 files changed, 22 insertions(+), 86 deletions(-)
diff --git a/include/linux/padata.h b/include/linux/padata.h
index 5d13d25da2c8..d803397a28f7 100644
--- a/include/linux/padata.h
+++ b/include/linux/padata.h
@@ -24,7 +24,6 @@
#include <linux/workqueue.h>
#include <linux/spinlock.h>
#include <linux/list.h>
-#include <linux/timer.h>
#include <linux/notifier.h>
#include <linux/kobject.h>
@@ -85,18 +84,14 @@ struct padata_serial_queue {
* @serial: List to wait for serialization after reordering.
* @pwork: work struct for parallelization.
* @swork: work struct for serialization.
- * @pd: Backpointer to the internal control structure.
* @work: work struct for parallelization.
- * @reorder_work: work struct for reordering.
* @num_obj: Number of objects that are processed by this cpu.
* @cpu_index: Index of the cpu.
*/
struct padata_parallel_queue {
struct padata_list parallel;
struct padata_list reorder;
- struct parallel_data *pd;
struct work_struct work;
- struct work_struct reorder_work;
atomic_t num_obj;
int cpu_index;
};
@@ -122,10 +117,10 @@ struct padata_cpumask {
* @reorder_objects: Number of objects waiting in the reorder queues.
* @refcnt: Number of objects holding a reference on this parallel_data.
* @max_seq_nr: Maximal used sequence number.
+ * @cpu: Next CPU to be processed.
* @cpumask: The cpumasks in use for parallel and serial workers.
+ * @reorder_work: work struct for reordering.
* @lock: Reorder lock.
- * @processed: Number of already processed objects.
- * @timer: Reorder timer.
*/
struct parallel_data {
struct padata_instance *pinst;
@@ -134,10 +129,10 @@ struct parallel_data {
atomic_t reorder_objects;
atomic_t refcnt;
atomic_t seq_nr;
+ int cpu;
struct padata_cpumask cpumask;
+ struct work_struct reorder_work;
spinlock_t lock ____cacheline_aligned;
- unsigned int processed;
- struct timer_list timer;
};
/**
diff --git a/kernel/padata.c b/kernel/padata.c
index c280cb153915..47dc31ce15ac 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -167,23 +167,12 @@ EXPORT_SYMBOL(padata_do_parallel);
*/
static struct padata_priv *padata_get_next(struct parallel_data *pd)
{
- int cpu, num_cpus;
- unsigned int next_nr, next_index;
struct padata_parallel_queue *next_queue;
struct padata_priv *padata;
struct padata_list *reorder;
+ int cpu = pd->cpu;
- num_cpus = cpumask_weight(pd->cpumask.pcpu);
-
- /*
- * Calculate the percpu reorder queue and the sequence
- * number of the next object.
- */
- next_nr = pd->processed;
- next_index = next_nr % num_cpus;
- cpu = padata_index_to_cpu(pd, next_index);
next_queue = per_cpu_ptr(pd->pqueue, cpu);
-
reorder = &next_queue->reorder;
spin_lock(&reorder->lock);
@@ -194,7 +183,8 @@ static struct padata_priv *padata_get_next(struct parallel_data *pd)
list_del_init(&padata->list);
atomic_dec(&pd->reorder_objects);
- pd->processed++;
+ pd->cpu = cpumask_next_wrap(cpu, pd->cpumask.pcpu, -1,
+ false);
spin_unlock(&reorder->lock);
goto out;
@@ -217,6 +207,7 @@ static void padata_reorder(struct parallel_data *pd)
struct padata_priv *padata;
struct padata_serial_queue *squeue;
struct padata_instance *pinst = pd->pinst;
+ struct padata_parallel_queue *next_queue;
/*
* We need to ensure that only one cpu can work on dequeueing of
@@ -248,7 +239,6 @@ static void padata_reorder(struct parallel_data *pd)
* so exit immediately.
*/
if (PTR_ERR(padata) == -ENODATA) {
- del_timer(&pd->timer);
spin_unlock_bh(&pd->lock);
return;
}
@@ -267,70 +257,29 @@ static void padata_reorder(struct parallel_data *pd)
/*
* The next object that needs serialization might have arrived to
- * the reorder queues in the meantime, we will be called again
- * from the timer function if no one else cares for it.
+ * the reorder queues in the meantime.
*
- * Ensure reorder_objects is read after pd->lock is dropped so we see
- * an increment from another task in padata_do_serial. Pairs with
+ * Ensure reorder queue is read after pd->lock is dropped so we see
+ * new objects from another task in padata_do_serial. Pairs with
* smp_mb__after_atomic in padata_do_serial.
*/
smp_mb();
- if (atomic_read(&pd->reorder_objects)
- && !(pinst->flags & PADATA_RESET))
- mod_timer(&pd->timer, jiffies + HZ);
- else
- del_timer(&pd->timer);
- return;
+ next_queue = per_cpu_ptr(pd->pqueue, pd->cpu);
+ if (!list_empty(&next_queue->reorder.list))
+ queue_work(pinst->wq, &pd->reorder_work);
}
static void invoke_padata_reorder(struct work_struct *work)
{
- struct padata_parallel_queue *pqueue;
struct parallel_data *pd;
local_bh_disable();
- pqueue = container_of(work, struct padata_parallel_queue, reorder_work);
- pd = pqueue->pd;
+ pd = container_of(work, struct parallel_data, reorder_work);
padata_reorder(pd);
local_bh_enable();
}
-static void padata_reorder_timer(struct timer_list *t)
-{
- struct parallel_data *pd = from_timer(pd, t, timer);
- unsigned int weight;
- int target_cpu, cpu;
-
- cpu = get_cpu();
-
- /* We don't lock pd here to not interfere with parallel processing
- * padata_reorder() calls on other CPUs. We just need any CPU out of
- * the cpumask.pcpu set. It would be nice if it's the right one but
- * it doesn't matter if we're off to the next one by using an outdated
- * pd->processed value.
- */
- weight = cpumask_weight(pd->cpumask.pcpu);
- target_cpu = padata_index_to_cpu(pd, pd->processed % weight);
-
- /* ensure to call the reorder callback on the correct CPU */
- if (cpu != target_cpu) {
- struct padata_parallel_queue *pqueue;
- struct padata_instance *pinst;
-
- /* The timer function is serialized wrt itself -- no locking
- * needed.
- */
- pinst = pd->pinst;
- pqueue = per_cpu_ptr(pd->pqueue, target_cpu);
- queue_work_on(target_cpu, pinst->wq, &pqueue->reorder_work);
- } else {
- padata_reorder(pd);
- }
-
- put_cpu();
-}
-
static void padata_serial_worker(struct work_struct *serial_work)
{
struct padata_serial_queue *squeue;
@@ -384,9 +333,8 @@ void padata_do_serial(struct padata_priv *padata)
cpu = get_cpu();
- /* We need to run on the same CPU padata_do_parallel(.., padata, ..)
- * was called on -- or, at least, enqueue the padata object into the
- * correct per-cpu queue.
+ /* We need to enqueue the padata object into the correct
+ * per-cpu queue.
*/
if (cpu != padata->cpu) {
reorder_via_wq = 1;
@@ -396,12 +344,12 @@ void padata_do_serial(struct padata_priv *padata)
pqueue = per_cpu_ptr(pd->pqueue, cpu);
spin_lock(&pqueue->reorder.lock);
- atomic_inc(&pd->reorder_objects);
list_add_tail(&padata->list, &pqueue->reorder.list);
+ atomic_inc(&pd->reorder_objects);
spin_unlock(&pqueue->reorder.lock);
/*
- * Ensure the atomic_inc of reorder_objects above is ordered correctly
+ * Ensure the addition to the reorder list is ordered correctly
* with the trylock of pd->lock in padata_reorder. Pairs with smp_mb
* in padata_reorder.
*/
@@ -409,13 +357,7 @@ void padata_do_serial(struct padata_priv *padata)
put_cpu();
- /* If we're running on the wrong CPU, call padata_reorder() via a
- * kernel worker.
- */
- if (reorder_via_wq)
- queue_work_on(cpu, pd->pinst->wq, &pqueue->reorder_work);
- else
- padata_reorder(pd);
+ padata_reorder(pd);
}
EXPORT_SYMBOL(padata_do_serial);
@@ -471,14 +413,12 @@ static void padata_init_pqueues(struct parallel_data *pd)
continue;
}
- pqueue->pd = pd;
pqueue->cpu_index = cpu_index;
cpu_index++;
__padata_list_init(&pqueue->reorder);
__padata_list_init(&pqueue->parallel);
INIT_WORK(&pqueue->work, padata_parallel_worker);
- INIT_WORK(&pqueue->reorder_work, invoke_padata_reorder);
atomic_set(&pqueue->num_obj, 0);
}
}
@@ -506,12 +446,13 @@ static struct parallel_data *padata_alloc_pd(struct padata_instance *pinst,
padata_init_pqueues(pd);
padata_init_squeues(pd);
- timer_setup(&pd->timer, padata_reorder_timer, 0);
atomic_set(&pd->seq_nr, -1);
atomic_set(&pd->reorder_objects, 0);
atomic_set(&pd->refcnt, 1);
pd->pinst = pinst;
spin_lock_init(&pd->lock);
+ pd->cpu = cpumask_first(pcpumask);
+ INIT_WORK(&pd->reorder_work, invoke_padata_reorder);
return pd;
--
2.26.2
I've backported fixes for I²C and media controller devices, dealing
with the lifetime of related cdev and struct device instances and some
similar race conditions. Fixing the lifetime issue for watchdog
devices looks impractical for 4.4, as it depends on a big refactoring
in 4.5.
All but one of these are already included in or queued for the later
stable branches. You dropped the I²C lifetime fix for 4.9, but I hope
my previous replies persuaded you that it is valid.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
From: Mathias Krause <minipli(a)googlemail.com>
[ Upstream commit 1bd845bcb41d5b7f83745e0cb99273eb376f2ec5 ]
The parallel queue per-cpu data structure gets initialized only for CPUs
in the 'pcpu' CPU mask set. This is not sufficient as the reorder timer
may run on a different CPU and might wrongly decide it's the target CPU
for the next reorder item as per-cpu memory gets memset(0) and we might
be waiting for the first CPU in cpumask.pcpu, i.e. cpu_index 0.
Make the '__this_cpu_read(pd->pqueue->cpu_index) == next_queue->cpu_index'
compare in padata_get_next() fail in this case by initializing the
cpu_index member of all per-cpu parallel queues. Use -1 for unused ones.
Signed-off-by: Mathias Krause <minipli(a)googlemail.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Daniel Jordan <daniel.m.jordan(a)oracle.com>
---
kernel/padata.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 693536efccf9..52a1d3fd13b5 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -462,8 +462,14 @@ static void padata_init_pqueues(struct parallel_data *pd)
struct padata_parallel_queue *pqueue;
cpu_index = 0;
- for_each_cpu(cpu, pd->cpumask.pcpu) {
+ for_each_possible_cpu(cpu) {
pqueue = per_cpu_ptr(pd->pqueue, cpu);
+
+ if (!cpumask_test_cpu(cpu, pd->cpumask.pcpu)) {
+ pqueue->cpu_index = -1;
+ continue;
+ }
+
pqueue->pd = pd;
pqueue->cpu_index = cpu_index;
cpu_index++;
--
2.26.2
From: Mathias Krause <minipli(a)googlemail.com>
[ Upstream commit 1bd845bcb41d5b7f83745e0cb99273eb376f2ec5 ]
The parallel queue per-cpu data structure gets initialized only for CPUs
in the 'pcpu' CPU mask set. This is not sufficient as the reorder timer
may run on a different CPU and might wrongly decide it's the target CPU
for the next reorder item as per-cpu memory gets memset(0) and we might
be waiting for the first CPU in cpumask.pcpu, i.e. cpu_index 0.
Make the '__this_cpu_read(pd->pqueue->cpu_index) == next_queue->cpu_index'
compare in padata_get_next() fail in this case by initializing the
cpu_index member of all per-cpu parallel queues. Use -1 for unused ones.
Signed-off-by: Mathias Krause <minipli(a)googlemail.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Daniel Jordan <daniel.m.jordan(a)oracle.com>
---
kernel/padata.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 40a0ebb8ea51..858e82179744 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -462,8 +462,14 @@ static void padata_init_pqueues(struct parallel_data *pd)
struct padata_parallel_queue *pqueue;
cpu_index = 0;
- for_each_cpu(cpu, pd->cpumask.pcpu) {
+ for_each_possible_cpu(cpu) {
pqueue = per_cpu_ptr(pd->pqueue, cpu);
+
+ if (!cpumask_test_cpu(cpu, pd->cpumask.pcpu)) {
+ pqueue->cpu_index = -1;
+ continue;
+ }
+
pqueue->pd = pd;
pqueue->cpu_index = cpu_index;
cpu_index++;
--
2.26.2
The patch titled
Subject: mm: ptdump: expand type of 'val' in note_page()
has been added to the -mm tree. Its filename is
mm-ptdump-expand-type-of-val-in-note_page.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-ptdump-expand-type-of-val-in-no…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-ptdump-expand-type-of-val-in-no…
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/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Steven Price <steven.price(a)arm.com>
Subject: mm: ptdump: expand type of 'val' in note_page()
The page table entry is passed in the 'val' argument to note_page(),
however this was previously an "unsigned long" which is fine on 64-bit
platforms. But for 32 bit x86 it is not always big enough to contain a
page table entry which may be 64 bits.
Change the type to u64 to ensure that it is always big enough.
Link: http://lkml.kernel.org/r/20200521152308.33096-3-steven.price@arm.com
Signed-off-by: Steven Price <steven.price(a)arm.com>
Reported-by: Jan Beulich <jbeulich(a)suse.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/arm64/mm/dump.c | 2 +-
arch/x86/mm/dump_pagetables.c | 2 +-
include/linux/ptdump.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- a/arch/arm64/mm/dump.c~mm-ptdump-expand-type-of-val-in-note_page
+++ a/arch/arm64/mm/dump.c
@@ -247,7 +247,7 @@ static void note_prot_wx(struct pg_state
}
static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
- unsigned long val)
+ u64 val)
{
struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
static const char units[] = "KMGTPE";
--- a/arch/x86/mm/dump_pagetables.c~mm-ptdump-expand-type-of-val-in-note_page
+++ a/arch/x86/mm/dump_pagetables.c
@@ -273,7 +273,7 @@ static void effective_prot(struct ptdump
* print what we collected so far.
*/
static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
- unsigned long val)
+ u64 val)
{
struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
pgprotval_t new_prot, new_eff;
--- a/include/linux/ptdump.h~mm-ptdump-expand-type-of-val-in-note_page
+++ a/include/linux/ptdump.h
@@ -13,7 +13,7 @@ struct ptdump_range {
struct ptdump_state {
/* level is 0:PGD to 4:PTE, or -1 if unknown */
void (*note_page)(struct ptdump_state *st, unsigned long addr,
- int level, unsigned long val);
+ int level, u64 val);
void (*effective_prot)(struct ptdump_state *st, int level, u64 val);
const struct ptdump_range *range;
};
_
Patches currently in -mm which might be from steven.price(a)arm.com are
x86-mm-ptdump-calculate-effective-permissions-correctly.patch
mm-ptdump-expand-type-of-val-in-note_page.patch
The patch titled
Subject: x86: mm: ptdump: calculate effective permissions correctly
has been added to the -mm tree. Its filename is
x86-mm-ptdump-calculate-effective-permissions-correctly.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/x86-mm-ptdump-calculate-effective-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/x86-mm-ptdump-calculate-effective-…
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/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Steven Price <steven.price(a)arm.com>
Subject: x86: mm: ptdump: calculate effective permissions correctly
Patch series "Fix W+X debug feature on x86"
Jan alerted me[1] that the W+X detection debug feature was broken in x86
by my change[2] to switch x86 to use the generic ptdump infrastructure.
Fundamentally the approach of trying to move the calculation of effective
permissions into note_page() was broken because note_page() is only called
for 'leaf' entries and the effective permissions are passed down via the
internal nodes of the page tree. The solution I've taken here is to
create a new (optional) callback which is called for all nodes of the page
tree and therefore can calculate the effective permissions.
Secondly on some configurations (32 bit with PAE) "unsigned long" is not
large enough to store the table entries. The fix here is simple - let's
just use a u64.
[1] https://lore.kernel.org/lkml/d573dc7e-e742-84de-473d-f971142fa319@suse.com/
[2] 2ae27137b2db ("x86: mm: convert dump_pagetables to use walk_page_range")
This patch (of 2):
By switching the x86 page table dump code to use the generic code the
effective permissions are no longer calculated correctly because the
note_page() function is only called for *leaf* entries. To calculate the
actual effective permissions it is necessary to observe the full hierarchy
of the page tree.
Introduce a new callback for ptdump which is called for every entry and
can therefore update the prot_levels array correctly. note_page() can
then simply access the appropriate element in the array.
Link: http://lkml.kernel.org/r/20200521152308.33096-1-steven.price@arm.com
Link: http://lkml.kernel.org/r/20200521152308.33096-2-steven.price@arm.com
Fixes: 2ae27137b2db ("x86: mm: convert dump_pagetables to use walk_page_range")
Signed-off-by: Steven Price <steven.price(a)arm.com>
Reported-by: Jan Beulich <jbeulich(a)suse.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/x86/mm/dump_pagetables.c | 31 +++++++++++++++++++------------
include/linux/ptdump.h | 1 +
mm/ptdump.c | 17 ++++++++++++++++-
3 files changed, 36 insertions(+), 13 deletions(-)
--- a/arch/x86/mm/dump_pagetables.c~x86-mm-ptdump-calculate-effective-permissions-correctly
+++ a/arch/x86/mm/dump_pagetables.c
@@ -249,10 +249,22 @@ static void note_wx(struct pg_state *st,
(void *)st->start_address);
}
-static inline pgprotval_t effective_prot(pgprotval_t prot1, pgprotval_t prot2)
+static void effective_prot(struct ptdump_state *pt_st, int level, u64 val)
{
- return (prot1 & prot2 & (_PAGE_USER | _PAGE_RW)) |
- ((prot1 | prot2) & _PAGE_NX);
+ struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
+ pgprotval_t prot = val & PTE_FLAGS_MASK;
+ pgprotval_t effective;
+
+ if (level > 0) {
+ pgprotval_t higher_prot = st->prot_levels[level - 1];
+
+ effective = (higher_prot & prot & (_PAGE_USER | _PAGE_RW)) |
+ ((higher_prot | prot) & _PAGE_NX);
+ } else {
+ effective = prot;
+ }
+
+ st->prot_levels[level] = effective;
}
/*
@@ -270,16 +282,10 @@ static void note_page(struct ptdump_stat
struct seq_file *m = st->seq;
new_prot = val & PTE_FLAGS_MASK;
+ new_eff = st->prot_levels[level];
- if (level > 0) {
- new_eff = effective_prot(st->prot_levels[level - 1],
- new_prot);
- } else {
- new_eff = new_prot;
- }
-
- if (level >= 0)
- st->prot_levels[level] = new_eff;
+ if (!val)
+ new_eff = 0;
/*
* If we have a "break" in the series, we need to flush the state that
@@ -374,6 +380,7 @@ static void ptdump_walk_pgd_level_core(s
struct pg_state st = {
.ptdump = {
.note_page = note_page,
+ .effective_prot = effective_prot,
.range = ptdump_ranges
},
.level = -1,
--- a/include/linux/ptdump.h~x86-mm-ptdump-calculate-effective-permissions-correctly
+++ a/include/linux/ptdump.h
@@ -14,6 +14,7 @@ struct ptdump_state {
/* level is 0:PGD to 4:PTE, or -1 if unknown */
void (*note_page)(struct ptdump_state *st, unsigned long addr,
int level, unsigned long val);
+ void (*effective_prot)(struct ptdump_state *st, int level, u64 val);
const struct ptdump_range *range;
};
--- a/mm/ptdump.c~x86-mm-ptdump-calculate-effective-permissions-correctly
+++ a/mm/ptdump.c
@@ -36,6 +36,9 @@ static int ptdump_pgd_entry(pgd_t *pgd,
return note_kasan_page_table(walk, addr);
#endif
+ if (st->effective_prot)
+ st->effective_prot(st, 0, pgd_val(val));
+
if (pgd_leaf(val))
st->note_page(st, addr, 0, pgd_val(val));
@@ -53,6 +56,9 @@ static int ptdump_p4d_entry(p4d_t *p4d,
return note_kasan_page_table(walk, addr);
#endif
+ if (st->effective_prot)
+ st->effective_prot(st, 1, p4d_val(val));
+
if (p4d_leaf(val))
st->note_page(st, addr, 1, p4d_val(val));
@@ -70,6 +76,9 @@ static int ptdump_pud_entry(pud_t *pud,
return note_kasan_page_table(walk, addr);
#endif
+ if (st->effective_prot)
+ st->effective_prot(st, 2, pud_val(val));
+
if (pud_leaf(val))
st->note_page(st, addr, 2, pud_val(val));
@@ -87,6 +96,8 @@ static int ptdump_pmd_entry(pmd_t *pmd,
return note_kasan_page_table(walk, addr);
#endif
+ if (st->effective_prot)
+ st->effective_prot(st, 3, pmd_val(val));
if (pmd_leaf(val))
st->note_page(st, addr, 3, pmd_val(val));
@@ -97,8 +108,12 @@ static int ptdump_pte_entry(pte_t *pte,
unsigned long next, struct mm_walk *walk)
{
struct ptdump_state *st = walk->private;
+ pte_t val = READ_ONCE(*pte);
+
+ if (st->effective_prot)
+ st->effective_prot(st, 4, pte_val(val));
- st->note_page(st, addr, 4, pte_val(READ_ONCE(*pte)));
+ st->note_page(st, addr, 4, pte_val(val));
return 0;
}
_
Patches currently in -mm which might be from steven.price(a)arm.com are
x86-mm-ptdump-calculate-effective-permissions-correctly.patch
mm-ptdump-expand-type-of-val-in-note_page.patch
I hope you are doing great?
This is Felix from Toronto-Canada. I have a lucrative business
offer that will benefit us both immensely within a very short
period of time. However, I need your initial approval of interest
prior to further and complete details regarding the deal.
Thanks,
Felix.
The ABI is broken and we cannot support it properly. Turn it off.
If this causes a meaningful performance regression for someone, KVM
can introduce an improved ABI that is supportable.
Cc: stable(a)vger.kernel.org
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
---
arch/x86/kernel/kvm.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 93ab0cbd304e..e6f2aefa298b 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -318,11 +318,26 @@ static void kvm_guest_cpu_init(void)
pa = slow_virt_to_phys(this_cpu_ptr(&apf_reason));
-#ifdef CONFIG_PREEMPTION
- pa |= KVM_ASYNC_PF_SEND_ALWAYS;
-#endif
pa |= KVM_ASYNC_PF_ENABLED;
+ /*
+ * We do not set KVM_ASYNC_PF_SEND_ALWAYS. With the current
+ * KVM paravirt ABI, the following scenario is possible:
+ *
+ * #PF: async page fault (KVM_PV_REASON_PAGE_NOT_PRESENT)
+ * NMI before CR2 or KVM_PF_REASON_PAGE_NOT_PRESENT
+ * NMI accesses user memory, e.g. due to perf
+ * #PF: normal page fault
+ * #PF reads CR2 and apf_reason -- apf_reason should be 0
+ *
+ * outer #PF reads CR2 and apf_reason -- apf_reason should be
+ * KVM_PV_REASON_PAGE_NOT_PRESENT
+ *
+ * There is no possible way that both reads of CR2 and
+ * apf_reason get the correct values. Fixing this would
+ * require paravirt ABI changes.
+ */
+
if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF_VMEXIT))
pa |= KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT;
--
2.24.1
I noticed that commit 07928d9bfc81 "padata: Remove broken queue
flushing" has been backported to most stable branches, but commit
6fc4dbcf0276 "padata: Replace delayed timer with immediate workqueue in
padata_reorder" has not.
Is this correct? What prevents the parallel_data ref-count from
dropping to 0 while the timer is scheduled?
Ben.
--
Ben Hutchings
Larkinson's Law: All laws are basically false.
This is a note to let you know that I've just added the patch titled
kobject: Make sure the parent does not get released before its
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 4ef12f7198023c09ad6d25b652bd8748c965c7fa Mon Sep 17 00:00:00 2001
From: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
Date: Wed, 13 May 2020 18:18:40 +0300
Subject: kobject: Make sure the parent does not get released before its
children
In the function kobject_cleanup(), kobject_del(kobj) is
called before the kobj->release(). That makes it possible to
release the parent of the kobject before the kobject itself.
To fix that, adding function __kboject_del() that does
everything that kobject_del() does except release the parent
reference. kobject_cleanup() then calls __kobject_del()
instead of kobject_del(), and separately decrements the
reference count of the parent kobject after kobj->release()
has been called.
Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org>
Reported-by: kernel test robot <rong.a.chen(a)intel.com>
Fixes: 7589238a8cf3 ("Revert "software node: Simplify software_node_release() function"")
Suggested-by: "Rafael J. Wysocki" <rafael(a)kernel.org>
Signed-off-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Reviewed-by: Brendan Higgins <brendanhiggins(a)google.com>
Tested-by: Brendan Higgins <brendanhiggins(a)google.com>
Acked-by: Randy Dunlap <rdunlap(a)infradead.org>
Link: https://lore.kernel.org/r/20200513151840.36400-1-heikki.krogerus@linux.inte…
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/kobject.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/lib/kobject.c b/lib/kobject.c
index 83198cb37d8d..2bd631460e18 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -599,14 +599,7 @@ int kobject_move(struct kobject *kobj, struct kobject *new_parent)
}
EXPORT_SYMBOL_GPL(kobject_move);
-/**
- * kobject_del() - Unlink kobject from hierarchy.
- * @kobj: object.
- *
- * This is the function that should be called to delete an object
- * successfully added via kobject_add().
- */
-void kobject_del(struct kobject *kobj)
+static void __kobject_del(struct kobject *kobj)
{
struct kernfs_node *sd;
const struct kobj_type *ktype;
@@ -625,9 +618,23 @@ void kobject_del(struct kobject *kobj)
kobj->state_in_sysfs = 0;
kobj_kset_leave(kobj);
- kobject_put(kobj->parent);
kobj->parent = NULL;
}
+
+/**
+ * kobject_del() - Unlink kobject from hierarchy.
+ * @kobj: object.
+ *
+ * This is the function that should be called to delete an object
+ * successfully added via kobject_add().
+ */
+void kobject_del(struct kobject *kobj)
+{
+ struct kobject *parent = kobj->parent;
+
+ __kobject_del(kobj);
+ kobject_put(parent);
+}
EXPORT_SYMBOL(kobject_del);
/**
@@ -663,6 +670,7 @@ EXPORT_SYMBOL(kobject_get_unless_zero);
*/
static void kobject_cleanup(struct kobject *kobj)
{
+ struct kobject *parent = kobj->parent;
struct kobj_type *t = get_ktype(kobj);
const char *name = kobj->name;
@@ -684,7 +692,7 @@ static void kobject_cleanup(struct kobject *kobj)
if (kobj->state_in_sysfs) {
pr_debug("kobject: '%s' (%p): auto cleanup kobject_del\n",
kobject_name(kobj), kobj);
- kobject_del(kobj);
+ __kobject_del(kobj);
}
if (t && t->release) {
@@ -698,6 +706,8 @@ static void kobject_cleanup(struct kobject *kobj)
pr_debug("kobject: '%s': free name\n", name);
kfree_const(name);
}
+
+ kobject_put(parent);
}
#ifdef CONFIG_DEBUG_KOBJECT_RELEASE
--
2.26.2
This is a note to let you know that I've just added the patch titled
driver core: Fix handling of SYNC_STATE_ONLY + STATELESS device links
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 44e960490ddf868fc9135151c4a658936e771dc2 Mon Sep 17 00:00:00 2001
From: Saravana Kannan <saravanak(a)google.com>
Date: Tue, 19 May 2020 21:36:26 -0700
Subject: driver core: Fix handling of SYNC_STATE_ONLY + STATELESS device links
Commit 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link
implementation") didn't completely fix STATELESS + SYNC_STATE_ONLY
handling.
What looks like an optimization in that commit is actually a bug that
causes an if condition to always take the else path. This prevents
reordering of devices in the dpm_list when a DL_FLAG_STATELESS device
link is create on top of an existing DL_FLAG_SYNC_STATE_ONLY device
link.
Fixes: 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link implementation")
Signed-off-by: Saravana Kannan <saravanak(a)google.com>
Cc: stable <stable(a)vger.kernel.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Link: https://lore.kernel.org/r/20200520043626.181820-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/core.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 4e0e430315d9..0cad34f1eede 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -360,12 +360,14 @@ struct device_link *device_link_add(struct device *consumer,
if (flags & DL_FLAG_STATELESS) {
kref_get(&link->kref);
- link->flags |= DL_FLAG_STATELESS;
if (link->flags & DL_FLAG_SYNC_STATE_ONLY &&
- !(link->flags & DL_FLAG_STATELESS))
+ !(link->flags & DL_FLAG_STATELESS)) {
+ link->flags |= DL_FLAG_STATELESS;
goto reorder;
- else
+ } else {
+ link->flags |= DL_FLAG_STATELESS;
goto out;
+ }
}
/*
--
2.26.2
From: Alexander Duyck <alexander.h.duyck(a)linux.intel.com>
We are seeing a deadlock in e1000 down when NAPI is being disabled. Looking
over the kernel function trace of the system it appears that the interface
is being closed and then a reset is hitting which deadlocks the interface
as the NAPI interface is already disabled.
To prevent this from happening I am disabling the reset task when
__E1000_DOWN is already set. In addition code has been added so that we set
the __E1000_DOWN while holding the __E1000_RESET flag in e1000_close in
order to guarantee that the reset task will not run after we have started
the close call.
CC: stable <stable(a)vger.kernel.org>
Signed-off-by: Alexander Duyck <alexander.h.duyck(a)linux.intel.com>
Tested-by: Maxim Zhukov <mussitantesmortem(a)gmail.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 05bc6e216bca..d9fa4600f745 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -542,8 +542,13 @@ void e1000_reinit_locked(struct e1000_adapter *adapter)
WARN_ON(in_interrupt());
while (test_and_set_bit(__E1000_RESETTING, &adapter->flags))
msleep(1);
- e1000_down(adapter);
- e1000_up(adapter);
+
+ /* only run the task if not already down */
+ if (!test_bit(__E1000_DOWN, &adapter->flags)) {
+ e1000_down(adapter);
+ e1000_up(adapter);
+ }
+
clear_bit(__E1000_RESETTING, &adapter->flags);
}
@@ -1433,10 +1438,15 @@ int e1000_close(struct net_device *netdev)
struct e1000_hw *hw = &adapter->hw;
int count = E1000_CHECK_RESET_COUNT;
- while (test_bit(__E1000_RESETTING, &adapter->flags) && count--)
+ while (test_and_set_bit(__E1000_RESETTING, &adapter->flags) && count--)
usleep_range(10000, 20000);
- WARN_ON(test_bit(__E1000_RESETTING, &adapter->flags));
+ WARN_ON(count < 0);
+
+ /* signal that we're down so that the reset task will no longer run */
+ set_bit(__E1000_DOWN, &adapter->flags);
+ clear_bit(__E1000_RESETTING, &adapter->flags);
+
e1000_down(adapter);
e1000_power_down_phy(adapter);
e1000_free_irq(adapter);
--
2.26.2
Please pick this fix for 4.19 and 5.4 stable branches:
commit d80b64ff297e40c2b6f7d7abc1b3eba70d22a068
Author: Miaohe Lin <linmiaohe(a)huawei.com>
Date: Sat Jan 4 16:56:49 2020 +0800
KVM: SVM: Fix potential memory leak in svm_cpu_init()
It applies cleanly to both.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
Please queue up the attached backport of commit 2351c88f8296 "watchdog:
Fix the race between the release of watchdog_core_data and cdev" for
4.14.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
Here are some fixes that required backporting for 4.14. All of them
are already present in later stable branches.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
The patch titled
Subject: z3fold: fix use-after-free when freeing handles
has been added to the -mm tree. Its filename is
z3fold-fix-use-after-free-when-freeing-handles.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/z3fold-fix-use-after-free-when-fre…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/z3fold-fix-use-after-free-when-fre…
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/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Uladzislau Rezki <uladzislau.rezki(a)sony.com>
Subject: z3fold: fix use-after-free when freeing handles
free_handle() for a foreign handle may race with inter-page compaction,
what can lead to memory corruption. To avoid that, take write lock not
read lock in free_handle to be synchronized with __release_z3fold_page().
For example KASAN can detect it:
[ 33.723357] ==================================================================
[ 33.723401] BUG: KASAN: use-after-free in LZ4_decompress_safe+0x2c4/0x3b8
[ 33.723418] Read of size 1 at addr ffffffc976695ca3 by task GoogleApiHandle/4121
[ 33.723428]
[ 33.723449] CPU: 0 PID: 4121 Comm: GoogleApiHandle Tainted: P S OE 4.19.81-perf+ #162
[ 33.723461] Hardware name: Sony Mobile Communications. PDX-203(KONA) (DT)
[ 33.723473] Call trace:
[ 33.723495] dump_backtrace+0x0/0x288
[ 33.723512] show_stack+0x14/0x20
[ 33.723533] dump_stack+0xe4/0x124
[ 33.723551] print_address_description+0x80/0x2e0
[ 33.723566] kasan_report+0x268/0x2d0
[ 33.723584] __asan_load1+0x4c/0x58
[ 33.723601] LZ4_decompress_safe+0x2c4/0x3b8
[ 33.723619] lz4_decompress_crypto+0x3c/0x70
[ 33.723636] crypto_decompress+0x58/0x70
[ 33.723656] zcomp_decompress+0xd4/0x120
...
Apart from that, initialize zhdr->mapped_count in init_z3fold_page() and
remove "newpage" variable because it is not used anywhere.
Link: http://lkml.kernel.org/r/20200520082100.28876-1-vitaly.wool@konsulko.com
Signed-off-by: Uladzislau Rezki <uladzislau.rezki(a)sony.com>
Signed-off-by: Vitaly Wool <vitaly.wool(a)konsulko.com>
Cc: Qian Cai <cai(a)lca.pw>
Cc: Raymond Jennings <shentino(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/z3fold.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/mm/z3fold.c~z3fold-fix-use-after-free-when-freeing-handles
+++ a/mm/z3fold.c
@@ -318,16 +318,16 @@ static inline void free_handle(unsigned
slots = handle_to_slots(handle);
write_lock(&slots->lock);
*(unsigned long *)handle = 0;
- write_unlock(&slots->lock);
- if (zhdr->slots == slots)
+ if (zhdr->slots == slots) {
+ write_unlock(&slots->lock);
return; /* simple case, nothing else to do */
+ }
/* we are freeing a foreign handle if we are here */
zhdr->foreign_handles--;
is_free = true;
- read_lock(&slots->lock);
if (!test_bit(HANDLES_ORPHANED, &slots->pool)) {
- read_unlock(&slots->lock);
+ write_unlock(&slots->lock);
return;
}
for (i = 0; i <= BUDDY_MASK; i++) {
@@ -336,7 +336,7 @@ static inline void free_handle(unsigned
break;
}
}
- read_unlock(&slots->lock);
+ write_unlock(&slots->lock);
if (is_free) {
struct z3fold_pool *pool = slots_to_pool(slots);
@@ -422,6 +422,7 @@ static struct z3fold_header *init_z3fold
zhdr->start_middle = 0;
zhdr->cpu = -1;
zhdr->foreign_handles = 0;
+ zhdr->mapped_count = 0;
zhdr->slots = slots;
zhdr->pool = pool;
INIT_LIST_HEAD(&zhdr->buddy);
_
Patches currently in -mm which might be from uladzislau.rezki(a)sony.com are
z3fold-fix-use-after-free-when-freeing-handles.patch
From: Masahiro Yamada <masahiroy(a)kernel.org>
[ Upstream commit b5154bf63e5577faaaca1d942df274f7de91dd2a ]
'make dtbs_check' checks the shecma in addition to building *.dtb files,
in other words, 'make dtbs_check' is a super-set of 'make dtbs'.
So, you do not have to do 'make dtbs dtbs_check', but I want to keep
the build system as robust as possible in any use.
Currently, 'dtbs' and 'dtbs_check' are independent of each other.
In parallel building, two threads descend into arch/*/boot/dts/,
one for dtbs and the other for dtbs_check, then end up with building
the same DTB simultaneously.
This commit fixes the concurrency issue. Otherwise, I see build errors
like follows:
$ make ARCH=arm64 defconfig
$ make -j16 ARCH=arm64 DT_SCHEMA_FILES=Documentation/devicetree/bindings/arm/psci.yaml dtbs dtbs_check
<snip>
DTC arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dtb
DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb
DTC arch/arm64/boot/dts/freescale/imx8mn-evk.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb
DTC arch/arm64/boot/dts/zte/zx296718-pcbox.dtb
DTC arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml
DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dtb
DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dtb
DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb
CHECK arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml
fixdep: error opening file: arch/arm64/boot/dts/allwinner/.sun50i-h6-orangepi-lite2.dtb.d: No such file or directory
make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb] Error 2
make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb'
make[2]: *** Waiting for unfinished jobs....
DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dtb
DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dtb
DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dtb
DTC arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dtb
fixdep: parse error; no targets found
make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb] Error 1
make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb'
make[1]: *** [scripts/Makefile.build:505: arch/arm64/boot/dts/allwinner] Error 2
make[1]: *** Waiting for unfinished jobs....
DTC arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb
Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org>
Reviewed-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
Makefile | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index d252219666fdd..6a8f0b278f1bb 100644
--- a/Makefile
+++ b/Makefile
@@ -1240,11 +1240,15 @@ ifneq ($(dtstree),)
$(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
PHONY += dtbs dtbs_install dtbs_check
-dtbs dtbs_check: include/config/kernel.release scripts_dtc
+dtbs: include/config/kernel.release scripts_dtc
$(Q)$(MAKE) $(build)=$(dtstree)
+ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),)
+dtbs: dt_binding_check
+endif
+
dtbs_check: export CHECK_DTBS=1
-dtbs_check: dt_binding_check
+dtbs_check: dtbs
dtbs_install:
$(Q)$(MAKE) $(dtbinst)=$(dtstree)
--
2.20.1
The patch titled
Subject: sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()
has been added to the -mm tree. Its filename is
sparc32-use-pud-rather-than-pgd-to-get-pmd-in-srmmu_nocache_init.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/sparc32-use-pud-rather-than-pgd-to…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/sparc32-use-pud-rather-than-pgd-to…
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/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Mike Rapoport <rppt(a)linux.ibm.com>
Subject: sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()
The kbuild test robot reported the following warning:
arch/sparc/mm/srmmu.c: In function 'srmmu_nocache_init':
>> arch/sparc/mm/srmmu.c:300:9: error: variable 'pud' set but not used
>> [-Werror=unused-but-set-variable]
300 | pud_t *pud;
This warning is caused by misprint in the page table traversal in
srmmu_nocache_init() function which accessed a PMD entry using PGD rather
than PUD.
Since sparc32 has only 3 page table levels, the PGD and PUD are essentially
the same and usage of __nocache_fix() removed the type checking.
Use PUD for the consistency and to silence the compiler warning.
Link: http://lkml.kernel.org/r/20200520132005.GM1059226@linux.ibm.com
Fixes: 7235db268a2777bc38 ("sparc32: use pgtable-nopud instead of 4level-fixup")
Signed-off-by: Mike Rapoport <rppt(a)linux.ibm.com>
Reported-by: kbuild test robot <lkp(a)intel.com>
Cc: David S. Miller <davem(a)davemloft.net>
Cc: Anatoly Pugachev <matorola(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/sparc/mm/srmmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/sparc/mm/srmmu.c~sparc32-use-pud-rather-than-pgd-to-get-pmd-in-srmmu_nocache_init
+++ a/arch/sparc/mm/srmmu.c
@@ -333,7 +333,7 @@ static void __init srmmu_nocache_init(vo
pgd = pgd_offset_k(vaddr);
p4d = p4d_offset(__nocache_fix(pgd), vaddr);
pud = pud_offset(__nocache_fix(p4d), vaddr);
- pmd = pmd_offset(__nocache_fix(pgd), vaddr);
+ pmd = pmd_offset(__nocache_fix(pud), vaddr);
pte = pte_offset_kernel(__nocache_fix(pmd), vaddr);
pteval = ((paddr >> 4) | SRMMU_ET_PTE | SRMMU_PRIV);
_
Patches currently in -mm which might be from rppt(a)linux.ibm.com are
sparc32-use-pud-rather-than-pgd-to-get-pmd-in-srmmu_nocache_init.patch
mm-memblock-replace-dereferences-of-memblock_regionnid-with-api-calls.patch
mm-make-early_pfn_to_nid-and-related-defintions-close-to-each-other.patch
mm-remove-config_have_memblock_node_map-option.patch
mm-free_area_init-use-maximal-zone-pfns-rather-than-zone-sizes.patch
mm-use-free_area_init-instead-of-free_area_init_nodes.patch
alpha-simplify-detection-of-memory-zone-boundaries.patch
arm-simplify-detection-of-memory-zone-boundaries.patch
arm64-simplify-detection-of-memory-zone-boundaries-for-uma-configs.patch
csky-simplify-detection-of-memory-zone-boundaries.patch
m68k-mm-simplify-detection-of-memory-zone-boundaries.patch
parisc-simplify-detection-of-memory-zone-boundaries.patch
sparc32-simplify-detection-of-memory-zone-boundaries.patch
unicore32-simplify-detection-of-memory-zone-boundaries.patch
xtensa-simplify-detection-of-memory-zone-boundaries.patch
mm-remove-early_pfn_in_nid-and-config_nodes_span_other_nodes.patch
mm-free_area_init-allow-defining-max_zone_pfn-in-descending-order.patch
mm-free_area_init-allow-defining-max_zone_pfn-in-descending-order-fix-2.patch
mm-rename-free_area_init_node-to-free_area_init_memoryless_node.patch
mm-clean-up-free_area_init_node-and-its-helpers.patch
mm-simplify-find_min_pfn_with_active_regions.patch
docs-vm-update-memory-models-documentation.patch
h8300-remove-usage-of-__arch_use_5level_hack.patch
arm-add-support-for-folded-p4d-page-tables.patch
arm-add-support-for-folded-p4d-page-tables-fix.patch
arm64-add-support-for-folded-p4d-page-tables.patch
hexagon-remove-__arch_use_5level_hack.patch
ia64-add-support-for-folded-p4d-page-tables.patch
nios2-add-support-for-folded-p4d-page-tables.patch
openrisc-add-support-for-folded-p4d-page-tables.patch
powerpc-add-support-for-folded-p4d-page-tables.patch
powerpc-add-support-for-folded-p4d-page-tables-fix.patch
powerpc-add-support-for-folded-p4d-page-tables-fix-2.patch
sh-drop-__pxd_offset-macros-that-duplicate-pxd_index-ones.patch
sh-add-support-for-folded-p4d-page-tables.patch
unicore32-remove-__arch_use_5level_hack.patch
asm-generic-remove-pgtable-nop4d-hackh.patch
mm-remove-__arch_has_5level_hack-and-include-asm-generic-5level-fixuph.patch
mm-dont-include-asm-pgtableh-if-linux-mmh-is-already-included.patch
mm-introduce-include-linux-pgtableh.patch
mm-reorder-includes-after-introduction-of-linux-pgtableh.patch
csky-replace-definitions-of-__pxd_offset-with-pxd_index.patch
m68k-mm-motorola-move-comment-about-page-table-allocation-funcitons.patch
m68k-mm-move-cachenocahe_page-definitions-close-to-their-user.patch
x86-mm-simplify-init_trampoline-and-surrounding-logic.patch
mm-pgtable-add-shortcuts-for-accessing-kernel-pmd-and-pte.patch
mm-pgtable-add-shortcuts-for-accessing-kernel-pmd-and-pte-fix.patch
mm-pgtable-add-shortcuts-for-accessing-kernel-pmd-and-pte-fix-2.patch
mm-consolidate-pte_index-and-pte_offset_-definitions.patch
mm-consolidate-pmd_index-and-pmd_offset-definitions.patch
mm-consolidate-pud_index-and-pud_offset-definitions.patch
mm-consolidate-pgd_index-and-pgd_offset_k-definitions.patch
Until this commit the mainline kernel version (this version) of the
vboxguest module contained a bug where it defined
VBGL_IOCTL_VMMDEV_REQUEST_BIG and VBGL_IOCTL_LOG using
_IOC(_IOC_READ | _IOC_WRITE, 'V', ...) instead of
_IO(V, ...) as the out of tree VirtualBox upstream version does.
Since the VirtualBox userspace bits are always built against VirtualBox
upstream's headers, this means that so far the mainline kernel version
of the vboxguest module has been failing these 2 ioctls with -ENOTTY.
I guess that VBGL_IOCTL_VMMDEV_REQUEST_BIG is never used causing us to
not hit that one and sofar the vboxguest driver has failed to actually
log any log messages passed it through VBGL_IOCTL_LOG.
This commit changes the VBGL_IOCTL_VMMDEV_REQUEST_BIG and VBGL_IOCTL_LOG
defines to match the out of tree VirtualBox upstream vboxguest version,
while keeping compatibility with the old wrong request defines so as
to not break the kernel ABI in case someone has been using the old
request defines.
Fixes: f6ddd094f579 ("virt: Add vboxguest driver for Virtual Box Guest integration UAPI")
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/virt/vboxguest/vboxguest_core.c | 4 +++-
drivers/virt/vboxguest/vboxguest_core.h | 15 +++++++++++++++
drivers/virt/vboxguest/vboxguest_linux.c | 3 ++-
include/uapi/linux/vboxguest.h | 4 ++--
4 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/virt/vboxguest/vboxguest_core.c b/drivers/virt/vboxguest/vboxguest_core.c
index b690a8a4bf9e..8fab04e76c14 100644
--- a/drivers/virt/vboxguest/vboxguest_core.c
+++ b/drivers/virt/vboxguest/vboxguest_core.c
@@ -1520,7 +1520,8 @@ int vbg_core_ioctl(struct vbg_session *session, unsigned int req, void *data)
/* For VMMDEV_REQUEST hdr->type != VBG_IOCTL_HDR_TYPE_DEFAULT */
if (req_no_size == VBG_IOCTL_VMMDEV_REQUEST(0) ||
- req == VBG_IOCTL_VMMDEV_REQUEST_BIG)
+ req == VBG_IOCTL_VMMDEV_REQUEST_BIG ||
+ req == VBG_IOCTL_VMMDEV_REQUEST_BIG_ALT)
return vbg_ioctl_vmmrequest(gdev, session, data);
if (hdr->type != VBG_IOCTL_HDR_TYPE_DEFAULT)
@@ -1558,6 +1559,7 @@ int vbg_core_ioctl(struct vbg_session *session, unsigned int req, void *data)
case VBG_IOCTL_HGCM_CALL(0):
return vbg_ioctl_hgcm_call(gdev, session, f32bit, data);
case VBG_IOCTL_LOG(0):
+ case VBG_IOCTL_LOG_ALT(0):
return vbg_ioctl_log(data);
}
diff --git a/drivers/virt/vboxguest/vboxguest_core.h b/drivers/virt/vboxguest/vboxguest_core.h
index 4188c12b839f..77c3a9c8255d 100644
--- a/drivers/virt/vboxguest/vboxguest_core.h
+++ b/drivers/virt/vboxguest/vboxguest_core.h
@@ -15,6 +15,21 @@
#include <linux/vboxguest.h>
#include "vmmdev.h"
+/*
+ * The mainline kernel version (this version) of the vboxguest module
+ * contained a bug where it defined VBGL_IOCTL_VMMDEV_REQUEST_BIG and
+ * VBGL_IOCTL_LOG using _IOC(_IOC_READ | _IOC_WRITE, 'V', ...) instead
+ * of _IO(V, ...) as the out of tree VirtualBox upstream version does.
+ *
+ * These _ALT definitions keep compatibility with the wrong defines the
+ * mainline kernel version used for a while.
+ * Note the VirtualBox userspace bits have always been built against
+ * VirtualBox upstream's headers, so this is likely not necessary. But
+ * we must never break our ABI so we keep these around to be 100% sure.
+ */
+#define VBG_IOCTL_VMMDEV_REQUEST_BIG_ALT _IOC(_IOC_READ | _IOC_WRITE, 'V', 3, 0)
+#define VBG_IOCTL_LOG_ALT(s) _IOC(_IOC_READ | _IOC_WRITE, 'V', 9, s)
+
struct vbg_session;
/** VBox guest memory balloon. */
diff --git a/drivers/virt/vboxguest/vboxguest_linux.c b/drivers/virt/vboxguest/vboxguest_linux.c
index 6e8c0f1c1056..32c2c52f7e84 100644
--- a/drivers/virt/vboxguest/vboxguest_linux.c
+++ b/drivers/virt/vboxguest/vboxguest_linux.c
@@ -131,7 +131,8 @@ static long vbg_misc_device_ioctl(struct file *filp, unsigned int req,
* the need for a bounce-buffer and another copy later on.
*/
is_vmmdev_req = (req & ~IOCSIZE_MASK) == VBG_IOCTL_VMMDEV_REQUEST(0) ||
- req == VBG_IOCTL_VMMDEV_REQUEST_BIG;
+ req == VBG_IOCTL_VMMDEV_REQUEST_BIG ||
+ req == VBG_IOCTL_VMMDEV_REQUEST_BIG_ALT;
if (is_vmmdev_req)
buf = vbg_req_alloc(size, VBG_IOCTL_HDR_TYPE_DEFAULT,
diff --git a/include/uapi/linux/vboxguest.h b/include/uapi/linux/vboxguest.h
index 9cec58a6a5ea..f79d7abe27db 100644
--- a/include/uapi/linux/vboxguest.h
+++ b/include/uapi/linux/vboxguest.h
@@ -103,7 +103,7 @@ VMMDEV_ASSERT_SIZE(vbg_ioctl_driver_version_info, 24 + 20);
/* IOCTL to perform a VMM Device request larger then 1KB. */
-#define VBG_IOCTL_VMMDEV_REQUEST_BIG _IOC(_IOC_READ | _IOC_WRITE, 'V', 3, 0)
+#define VBG_IOCTL_VMMDEV_REQUEST_BIG _IO('V', 3)
/** VBG_IOCTL_HGCM_CONNECT data structure. */
@@ -198,7 +198,7 @@ struct vbg_ioctl_log {
} u;
};
-#define VBG_IOCTL_LOG(s) _IOC(_IOC_READ | _IOC_WRITE, 'V', 9, s)
+#define VBG_IOCTL_LOG(s) _IO('V', 9)
/** VBG_IOCTL_WAIT_FOR_EVENTS data structure. */
--
2.26.2
Hi Greg and everyone,
On all kernels, SEV enabled guests hit might_sleep() warnings when a
driver (nvme in this case) allocates through the DMA API in a
non-blockable context:
BUG: sleeping function called from invalid context at mm/vmalloc.c:1710
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3383, name: fio
2 locks held by fio/3383:
#0: ffff93b6a8568348 (&sb->s_type->i_mutex_key#16){+.+.}, at: ext4_file_write_iter+0xa2/0x5d0
#1: ffffffffa52a61a0 (rcu_read_lock){....}, at: hctx_lock+0x1a/0xe0
CPU: 0 PID: 3383 Comm: fio Tainted: G W 5.5.10 #14
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
dump_stack+0x98/0xd5
___might_sleep+0x175/0x260
__might_sleep+0x4a/0x80
_vm_unmap_aliases+0x45/0x250
vm_unmap_aliases+0x19/0x20
__set_memory_enc_dec+0xa4/0x130
set_memory_decrypted+0x10/0x20
dma_direct_alloc_pages+0x148/0x150
dma_direct_alloc+0xe/0x10
dma_alloc_attrs+0x86/0xc0
dma_pool_alloc+0x16f/0x2b0
nvme_queue_rq+0x878/0xc30 [nvme]
__blk_mq_try_issue_directly+0x135/0x200
blk_mq_request_issue_directly+0x4f/0x80
blk_mq_try_issue_list_directly+0x46/0xb0
blk_mq_sched_insert_requests+0x19b/0x2b0
blk_mq_flush_plug_list+0x22f/0x3b0
blk_flush_plug_list+0xd1/0x100
blk_finish_plug+0x2c/0x40
iomap_dio_rw+0x427/0x490
ext4_file_write_iter+0x181/0x5d0
aio_write+0x109/0x1b0
io_submit_one+0x7d0/0xfa0
__x64_sys_io_submit+0xa2/0x280
do_syscall_64+0x5f/0x250
entry_SYSCALL_64_after_hwframe+0x49/0xbe
There is a series of patches in Christoph's dma-mapping.git repo in the
for-next branch on track for 5.8:
1d659236fb43 dma-pool: scale the default DMA coherent pool size with memory capacity
82fef0ad811f x86/mm: unencrypted non-blocking DMA allocations use coherent pools
2edc5bb3c5cc dma-pool: add pool sizes to debugfs
76a19940bd62 dma-direct: atomic allocations must come from atomic coherent pools
54adadf9b085 dma-pool: dynamically expanding atomic pools
c84dc6e68a1d dma-pool: add additional coherent pools to map to gfp mask
e860c299ac0d dma-remap: separate DMA atomic pools from direct remap code
We'd like to prepare backports to LTS kernels so that our guest images are
not modified by us and don't exhibit this issue.
They are bigger than we'd like:
arch/x86/Kconfig | 1 +
drivers/iommu/dma-iommu.c | 5 +-
include/linux/dma-direct.h | 2 +
include/linux/dma-mapping.h | 6 +-
kernel/dma/Kconfig | 6 +-
kernel/dma/Makefile | 1 +
kernel/dma/direct.c | 56 ++++++--
kernel/dma/pool.c | 264 ++++++++++++++++++++++++++++++++++++
kernel/dma/remap.c | 121 +----------------
9 files changed, 324 insertions(+), 138 deletions(-)
create mode 100644 kernel/dma/pool.c
But they apply relatively cleanly to more modern kernels like 5.4. We'd
like to backport these all the way to 4.19, however, otherwise guests
encounter these bugs.
The changes to kernel/dma/remap.c, for example, simply moves code to the
new pool.c. But that original code is actually in arch/arm64 in 4.19 and
was moved in 5.0:
commit 0c3b3171ceccb8830c2bb5adff1b4e9b204c1450
Author: Christoph Hellwig <hch(a)lst.de>
Date: Sun Nov 4 20:29:28 2018 +0100
dma-mapping: move the arm64 noncoherent alloc/free support to common code
commit f0edfea8ef93ed6cc5f747c46c85c8e53e0798a0
Author: Christoph Hellwig <hch(a)lst.de>
Date: Fri Aug 24 10:31:08 2018 +0200
dma-mapping: move the remap helpers to a separate file
And there are most certainly more dependencies to get a cleanly applying
series to 4.19.123. So the backports could be quite extensive.
Peter Gonda <pgonda(a)google.com> is currently handling these and we're
looking for advice: should we compile a full list of required backports
that would be needed to get a series that would only consist of minor
conflicts or is this going to be a non-starter?
Thanks!
Hi,
please apply upstream commit 629823b87240 ("igb: use igb_adapter->io_addr
instead of e1000_hw->hw_addr") to v4.4.y and to v4.9.y. The problem solved
with this commit has been observed in chromeos-4.4.
Thanks,
Guenter
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable/branch/linux-4.19.y/kernel/v4.19.124/p…
-------------------------------------------------------------------------------
stable/linux-4.19.y boot: 89 boots: 3 failed, 83 passed with 3 untried/unknown (v4.19.124)
Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.19.y/kernel/v4.19.1…
Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.19.y/kernel/v4.19.124/
Tree: stable
Branch: linux-4.19.y
Git Describe: v4.19.124
Git Commit: 1bab61d3e8cd96f2badf515dcb06e4e1029bc017
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tested: 56 unique boards, 18 SoC families, 18 builds out of 206
Boot Regressions Detected:
arm:
multi_v7_defconfig:
gcc-8:
omap3-beagle-xm:
lab-baylibre: new failure (last pass: v4.19.123)
versatile_defconfig:
gcc-8:
versatile-pb:
lab-collabora: new failure (last pass: v4.19.123)
arm64:
defconfig:
gcc-8:
meson-gxl-s905x-khadas-vim:
lab-baylibre: new failure (last pass: v4.19.123)
Boot Failures Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
multi_v7_defconfig:
gcc-8:
omap3-beagle-xm: 1 failed lab
arm64:
defconfig:
gcc-8:
meson-gxl-s905x-khadas-vim: 1 failed lab
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable/branch/linux-4.14.y/kernel/v4.14.181/p…
-------------------------------------------------------------------------------
stable/linux-4.14.y boot: 47 boots: 2 failed, 45 passed (v4.14.181)
Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.14.y/kernel/v4.14.1…
Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.14.y/kernel/v4.14.181/
Tree: stable
Branch: linux-4.14.y
Git Describe: v4.14.181
Git Commit: a41ba30d9df20fe141c92aacbb56b6b077f19716
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tested: 30 unique boards, 12 SoC families, 8 builds out of 201
Boot Regressions Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained:
lab-baylibre: failing since 117 days (last pass: v4.14.166 - first fail: v4.14.167)
Boot Failures Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
arm64:
defconfig:
gcc-8:
meson-gxm-q200: 1 failed lab
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable/branch/linux-5.6.y/kernel/v5.6.14/plan…
-------------------------------------------------------------------------------
stable/linux-5.6.y boot: 82 boots: 1 failed, 78 passed with 3 untried/unknown (v5.6.14)
Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-5.6.y/kernel/v5.6.14/
Full Build Summary: https://kernelci.org/build/stable/branch/linux-5.6.y/kernel/v5.6.14/
Tree: stable
Branch: linux-5.6.y
Git Describe: v5.6.14
Git Commit: e3ac9117b18596b7363d5b7904ab03a7d782b40c
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tested: 56 unique boards, 16 SoC families, 13 builds out of 200
Boot Regressions Detected:
arc:
hsdk_defconfig:
gcc-8:
hsdk:
lab-baylibre: new failure (last pass: v5.6.13)
arm:
sunxi_defconfig:
gcc-8:
sun8i-a83t-bananapi-m3:
lab-clabbe: new failure (last pass: v5.6.13)
arm64:
defconfig:
gcc-8:
meson-gxl-s805x-libretech-ac:
lab-baylibre: new failure (last pass: v5.6.12)
sun50i-h6-orangepi-3:
lab-clabbe: new failure (last pass: v5.6.12)
Boot Failure Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable/branch/linux-5.4.y/kernel/v5.4.42/plan…
-------------------------------------------------------------------------------
stable/linux-5.4.y boot: 84 boots: 1 failed, 81 passed with 2 untried/unknown (v5.4.42)
Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-5.4.y/kernel/v5.4.42/
Full Build Summary: https://kernelci.org/build/stable/branch/linux-5.4.y/kernel/v5.4.42/
Tree: stable
Branch: linux-5.4.y
Git Describe: v5.4.42
Git Commit: 1cdaf895c99d319c0007d0b62818cf85fc4b087f
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tested: 58 unique boards, 17 SoC families, 13 builds out of 200
Boot Regressions Detected:
arc:
hsdk_defconfig:
gcc-8:
hsdk:
lab-baylibre: failing since 5 days (last pass: v5.4.40 - first fail: v5.4.41)
arm64:
defconfig:
gcc-8:
meson-g12b-a311d-khadas-vim3:
lab-baylibre: new failure (last pass: v5.4.41)
Boot Failure Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
---
For more info write to <info(a)kernelci.org>
Potentially, hvc_open() can be called in parallel when two tasks calls
open() on /dev/hvcX. In such a scenario, if the hp->ops->notifier_add()
callback in the function fails, where it sets the tty->driver_data to
NULL, the parallel hvc_open() can see this NULL and cause a memory abort.
Hence, do a NULL check at the beginning, before proceeding ahead.
The issue can be easily reproduced by launching two tasks simultaneously
that does an open() call on /dev/hvcX.
For example:
$ cat /dev/hvc0 & cat /dev/hvc0 &
Cc: stable(a)vger.kernel.org
Signed-off-by: Raghavendra Rao Ananta <rananta(a)codeaurora.org>
---
drivers/tty/hvc/hvc_console.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 436cc51c92c3..80709f754cc8 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -350,6 +350,9 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
unsigned long flags;
int rc = 0;
+ if (!hp)
+ return -ENODEV;
+
spin_lock_irqsave(&hp->port.lock, flags);
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable/branch/linux-4.9.y/kernel/v4.9.224/pla…
-------------------------------------------------------------------------------
stable/linux-4.9.y boot: 39 boots: 1 failed, 37 passed with 1 untried/unknown (v4.9.224)
Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.9.y/kernel/v4.9.224/
Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.9.y/kernel/v4.9.224/
Tree: stable
Branch: linux-4.9.y
Git Describe: v4.9.224
Git Commit: e4ebe4fae299b559e683eb31a2dc950507842bf7
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tested: 22 unique boards, 10 SoC families, 10 builds out of 197
Boot Regressions Detected:
arm:
sunxi_defconfig:
gcc-8:
sun4i-a10-olinuxino-lime:
lab-baylibre: new failure (last pass: v4.9.223)
Boot Failure Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable/branch/linux-4.4.y/kernel/v4.4.224/pla…
-------------------------------------------------------------------------------
stable/linux-4.4.y boot: 30 boots: 3 failed, 27 passed (v4.4.224)
Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.4.y/kernel/v4.4.224/
Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.4.y/kernel/v4.4.224/
Tree: stable
Branch: linux-4.4.y
Git Describe: v4.4.224
Git Commit: d72237c1e00f85e5df1c040280d50561c8a28329
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tested: 16 unique boards, 8 SoC families, 9 builds out of 190
Boot Failures Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
imx_v4_v5_defconfig:
gcc-8:
imx27-phytec-phycard-s-rdk: 1 failed lab
multi_v5_defconfig:
gcc-8:
imx27-phytec-phycard-s-rdk: 1 failed lab
---
For more info write to <info(a)kernelci.org>
From: Chris Wilson <chris(a)chris-wilson.co.uk>
If we park/unpark faster than we can respond to RPS events, we never
will process a downclock event after expiring a waitboost, and thus we
will forever restart the GPU at max clocks even if the workload switches
and doesn't justify full power.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500
Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti(a)intel.com>
Cc: Lyude Paul <lyude(a)redhat.com>
Reviewed-by: Andi Shyti <andi.shyti(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200322163225.28791-1-chris@…
Cc: <stable(a)vger.kernel.org> # v5.5+
(cherry picked from commit 21abf0bf168dffff1192e0f072af1dc74ae1ff0e)
---
drivers/gpu/drm/i915/gt/intel_rps.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
index 6beaa2b4e8f7..32ccb4efb0d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -768,6 +768,19 @@ void intel_rps_park(struct intel_rps *rps)
intel_uncore_forcewake_get(rps_to_uncore(rps), FORCEWAKE_MEDIA);
rps_set(rps, rps->idle_freq, false);
intel_uncore_forcewake_put(rps_to_uncore(rps), FORCEWAKE_MEDIA);
+
+ /*
+ * Since we will try and restart from the previously requested
+ * frequency on unparking, treat this idle point as a downclock
+ * interrupt and reduce the frequency for resume. If we park/unpark
+ * more frequently than the rps worker can run, we will not respond
+ * to any EI and never see a change in frequency.
+ *
+ * (Note we accommodate Cherryview's limitation of only using an
+ * even bin by applying it to all.)
+ */
+ rps->cur_freq =
+ max_t(int, round_down(rps->cur_freq - 1, 2), rps->min_freq);
}
void intel_rps_boost(struct i915_request *rq)
From: Chris Wilson <chris(a)chris-wilson.co.uk>
If we use a non-forcewaked write to PMINTRMSK, it does not take effect
until much later, if at all, causing a loss of RPS interrupts and no GPU
reclocking, leaving the GPU running at the wrong frequency for long
periods of time.
Reported-by: Francisco Jerez <currojerez(a)riseup.net>
Suggested-by: Francisco Jerez <currojerez(a)riseup.net>
Fixes: 35cc7f32c298 ("drm/i915/gt: Use non-forcewake writes for RPS")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Francisco Jerez <currojerez(a)riseup.net>
Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com>
Cc: Andi Shyti <andi.shyti(a)intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala(a)linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti(a)intel.com>
Reviewed-by: Francisco Jerez <currojerez(a)riseup.net>
Cc: <stable(a)vger.kernel.org> # v5.6+
Link: https://patchwork.freedesktop.org/patch/msgid/20200415170318.16771-2-chris@…
(cherry picked from commit a080bd994c4023042a2b605c65fa10a25933f636)
---
drivers/gpu/drm/i915/gt/intel_rps.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
index c1a3d360de06..6beaa2b4e8f7 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -85,7 +85,8 @@ static void rps_enable_interrupts(struct intel_rps *rps)
gen6_gt_pm_enable_irq(gt, rps->pm_events);
spin_unlock_irq(>->irq_lock);
- set(gt->uncore, GEN6_PMINTRMSK, rps_pm_mask(rps, rps->cur_freq));
+ intel_uncore_write(gt->uncore,
+ GEN6_PMINTRMSK, rps_pm_mask(rps, rps->last_freq));
}
static void gen6_rps_reset_interrupts(struct intel_rps *rps)
@@ -119,7 +120,8 @@ static void rps_disable_interrupts(struct intel_rps *rps)
rps->pm_events = 0;
- set(gt->uncore, GEN6_PMINTRMSK, rps_pm_sanitize_mask(rps, ~0u));
+ intel_uncore_write(gt->uncore,
+ GEN6_PMINTRMSK, rps_pm_sanitize_mask(rps, ~0u));
spin_lock_irq(>->irq_lock);
gen6_gt_pm_disable_irq(gt, GEN6_PM_RPS_EVENTS);
The patch titled
Subject: sh: include linux/time_types.h for sockios
has been added to the -mm tree. Its filename is
sh-include-linux-time_typesh-for-sockios.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/sh-include-linux-time_typesh-for-s…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/sh-include-linux-time_typesh-for-s…
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/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Arnd Bergmann <arnd(a)arndb.de>
Subject: sh: include linux/time_types.h for sockios
Using the socket ioctls on arch/sh (and only there) causes build time
problems when __kernel_old_timeval/__kernel_old_timespec are not already
visible to the compiler.
Add an explict include line for the header that defines these
structures.
Link: http://lkml.kernel.org/r/20200519131327.1836482-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Reported-by: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de>
Tested-by: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de>
Fixes: 8c709f9a0693 ("y2038: sh: remove timeval/timespec usage from headers")
Fixes: 0768e17073dc ("net: socket: implement 64-bit timestamps")
Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp>
Cc: Rich Felker <dalias(a)libc.org>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/sh/include/uapi/asm/sockios.h | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/sh/include/uapi/asm/sockios.h~sh-include-linux-time_typesh-for-sockios
+++ a/arch/sh/include/uapi/asm/sockios.h
@@ -2,6 +2,8 @@
#ifndef __ASM_SH_SOCKIOS_H
#define __ASM_SH_SOCKIOS_H
+#include <linux/time_types.h>
+
/* Socket-level I/O control calls. */
#define FIOGETOWN _IOR('f', 123, int)
#define FIOSETOWN _IOW('f', 124, int)
_
Patches currently in -mm which might be from arnd(a)arndb.de are
sh-include-linux-time_typesh-for-sockios.patch
drm-remove-drm-specific-kmap_atomic-code-fix.patch
bitops-avoid-clang-shift-count-overflow-warnings.patch
ubsan-fix-gcc-10-warnings.patch
arm64-add-support-for-folded-p4d-page-tables-fix.patch
KVM stores the gfn in MMIO SPTEs as a caching optimization. These are split
in two parts, as in "[high 11111 low]", to thwart any attempt to use these bits
in an L1TF attack. This works as long as there are 5 free bits between
MAXPHYADDR and bit 50 (inclusive), leaving bit 51 free so that the MMIO
access triggers a reserved-bit-set page fault.
The bit positions however were computed wrongly for AMD processors that have
encryption support. In this case, x86_phys_bits is reduced (for example
from 48 to 43, to account for the C bit at position 47 and four bits used
internally to store the SEV ASID and other stuff) while x86_cache_bits in
would remain set to 48, and _all_ bits between the reduced MAXPHYADDR
and bit 51 are set. Then low_phys_bits would also cover some of the
bits that are set in the shadow_mmio_value, terribly confusing the gfn
caching mechanism.
To fix this, avoid splitting gfns as long as the processor does not have
the L1TF bug (which includes all AMD processors). When there is no
splitting, low_phys_bits can be set to the reduced MAXPHYADDR removing
the overlap. This fixes "npt=0" operation on EPYC processors.
Thanks to Maxim Levitsky for bisecting this bug.
Cc: stable(a)vger.kernel.org
Fixes: 52918ed5fcf0 ("KVM: SVM: Override default MMIO mask if memory encryption is enabled")
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 8071952e9cf2..86619631ff6a 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -335,6 +335,8 @@ void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value, u64 access_mask)
{
BUG_ON((u64)(unsigned)access_mask != access_mask);
BUG_ON((mmio_mask & mmio_value) != mmio_value);
+ WARN_ON(mmio_value & (shadow_nonpresent_or_rsvd_mask << shadow_nonpresent_or_rsvd_mask_len));
+ WARN_ON(mmio_value & shadow_nonpresent_or_rsvd_lower_gfn_mask);
shadow_mmio_value = mmio_value | SPTE_MMIO_MASK;
shadow_mmio_mask = mmio_mask | SPTE_SPECIAL_MASK;
shadow_mmio_access_mask = access_mask;
@@ -583,16 +585,15 @@ static void kvm_mmu_reset_all_pte_masks(void)
* the most significant bits of legal physical address space.
*/
shadow_nonpresent_or_rsvd_mask = 0;
- low_phys_bits = boot_cpu_data.x86_cache_bits;
- if (boot_cpu_data.x86_cache_bits <
- 52 - shadow_nonpresent_or_rsvd_mask_len) {
+ low_phys_bits = boot_cpu_data.x86_phys_bits;
+ if (boot_cpu_has_bug(X86_BUG_L1TF) &&
+ !WARN_ON_ONCE(boot_cpu_data.x86_cache_bits >=
+ 52 - shadow_nonpresent_or_rsvd_mask_len)) {
+ low_phys_bits = boot_cpu_data.x86_cache_bits
+ - shadow_nonpresent_or_rsvd_mask_len;
shadow_nonpresent_or_rsvd_mask =
- rsvd_bits(boot_cpu_data.x86_cache_bits -
- shadow_nonpresent_or_rsvd_mask_len,
- boot_cpu_data.x86_cache_bits - 1);
- low_phys_bits -= shadow_nonpresent_or_rsvd_mask_len;
- } else
- WARN_ON_ONCE(boot_cpu_has_bug(X86_BUG_L1TF));
+ rsvd_bits(low_phys_bits, boot_cpu_data.x86_cache_bits - 1);
+ }
shadow_nonpresent_or_rsvd_lower_gfn_mask =
GENMASK_ULL(low_phys_bits - 1, PAGE_SHIFT);
--
2.18.2
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-5.6.y/kernel/v5.6.13-1…
-------------------------------------------------------------------------------
stable-rc/linux-5.6.y boot: 163 boots: 3 failed, 148 passed with 5 offline, 6 untried/unknown, 1 conflict (v5.6.13-193-g67346f550ad8)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.6.y/kernel/v5.6.…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.6.y/kernel/v5.6.13-193-…
Tree: stable-rc
Branch: linux-5.6.y
Git Describe: v5.6.13-193-g67346f550ad8
Git Commit: 67346f550ad85f9ddd257856e32049416df51616
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 99 unique boards, 26 SoC families, 21 builds out of 200
Boot Regressions Detected:
arm:
exynos_defconfig:
gcc-8:
exynos5422-odroidxu3:
lab-collabora: failing since 1 day (last pass: v5.6.13 - first fail: v5.6.13-195-g4dae52cee3fd)
multi_v7_defconfig:
gcc-8:
sun8i-h2-plus-orangepi-r1:
lab-baylibre: new failure (last pass: v5.6.13-195-g4dae52cee3fd)
versatile_defconfig:
gcc-8:
versatile-pb:
lab-collabora: new failure (last pass: v5.6.13-195-g4dae52cee3fd)
Boot Failures Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
multi_v7_defconfig:
gcc-8:
bcm2836-rpi-2-b: 1 failed lab
exynos_defconfig:
gcc-8:
exynos5422-odroidxu3: 1 failed lab
Offline Platforms:
arm:
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
stih410-b2120: 1 offline lab
exynos_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
arm:
multi_v7_defconfig:
sun7i-a20-cubieboard2:
lab-clabbe: FAIL (gcc-8)
lab-baylibre: PASS (gcc-8)
---
For more info write to <info(a)kernelci.org>
The patch below does not apply to the 5.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 3100423dc133c25679dbaa1099404651b8ae3af9 Mon Sep 17 00:00:00 2001
From: Ahmad Fatoum <a.fatoum(a)pengutronix.de>
Date: Mon, 23 Mar 2020 09:19:33 +0100
Subject: [PATCH] ARM: imx: provide v7_cpu_resume() only on ARM_CPU_SUSPEND=y
512a928affd5 ("ARM: imx: build v7_cpu_resume() unconditionally")
introduced an unintended linker error for i.MX6 configurations that have
ARM_CPU_SUSPEND=n which can happen if neither CONFIG_PM, CONFIG_CPU_IDLE,
nor ARM_PSCI_FW are selected.
Fix this by having v7_cpu_resume() compiled only when cpu_resume() it
calls is available as well.
The C declaration for the function remains unguarded to avoid future code
inadvertently using a stub and introducing a regression to the bug the
original commit fixed.
Cc: <stable(a)vger.kernel.org>
Fixes: 512a928affd5 ("ARM: imx: build v7_cpu_resume() unconditionally")
Reported-by: Clemens Gruber <clemens.gruber(a)pqgruber.com>
Signed-off-by: Ahmad Fatoum <a.fatoum(a)pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 03506ce46149..e7364e6c8c6b 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -91,8 +91,10 @@ AFLAGS_suspend-imx6.o :=-Wa,-march=armv7-a
obj-$(CONFIG_SOC_IMX6) += suspend-imx6.o
obj-$(CONFIG_SOC_IMX53) += suspend-imx53.o
endif
+ifeq ($(CONFIG_ARM_CPU_SUSPEND),y)
AFLAGS_resume-imx6.o :=-Wa,-march=armv7-a
obj-$(CONFIG_SOC_IMX6) += resume-imx6.o
+endif
obj-$(CONFIG_SOC_IMX6) += pm-imx6.o
obj-$(CONFIG_SOC_IMX1) += mach-imx1.o
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From b2a5212fb634561bb734c6356904e37f6665b955 Mon Sep 17 00:00:00 2001
From: Daniel Borkmann <daniel(a)iogearbox.net>
Date: Fri, 15 May 2020 12:11:18 +0200
Subject: [PATCH] bpf: Restrict bpf_trace_printk()'s %s usage and add %pks,
%pus specifier
Usage of plain %s conversion specifier in bpf_trace_printk() suffers from the
very same issue as bpf_probe_read{,str}() helpers, that is, it is broken on
archs with overlapping address ranges.
While the helpers have been addressed through work in 6ae08ae3dea2 ("bpf: Add
probe_read_{user, kernel} and probe_read_{user, kernel}_str helpers"), we need
an option for bpf_trace_printk() as well to fix it.
Similarly as with the helpers, force users to make an explicit choice by adding
%pks and %pus specifier to bpf_trace_printk() which will then pick the corresponding
strncpy_from_unsafe*() variant to perform the access under KERNEL_DS or USER_DS.
The %pk* (kernel specifier) and %pu* (user specifier) can later also be extended
for other objects aside strings that are probed and printed under tracing, and
reused out of other facilities like bpf_seq_printf() or BTF based type printing.
Existing behavior of %s for current users is still kept working for archs where it
is not broken and therefore gated through CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE.
For archs not having this property we fall-back to pick probing under KERNEL_DS as
a sensible default.
Fixes: 8d3b7dce8622 ("bpf: add support for %s specifier to bpf_trace_printk()")
Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Reported-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
Cc: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Brendan Gregg <brendan.d.gregg(a)gmail.com>
Link: https://lore.kernel.org/bpf/20200515101118.6508-4-daniel@iogearbox.net
diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index 8ebe46b1af39..5dfcc4592b23 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -112,6 +112,20 @@ used when printing stack backtraces. The specifier takes into
consideration the effect of compiler optimisations which may occur
when tail-calls are used and marked with the noreturn GCC attribute.
+Probed Pointers from BPF / tracing
+----------------------------------
+
+::
+
+ %pks kernel string
+ %pus user string
+
+The ``k`` and ``u`` specifiers are used for printing prior probed memory from
+either kernel memory (k) or user memory (u). The subsequent ``s`` specifier
+results in printing a string. For direct use in regular vsnprintf() the (k)
+and (u) annotation is ignored, however, when used out of BPF's bpf_trace_printk(),
+for example, it reads the memory it is pointing to without faulting.
+
Kernel Pointers
---------------
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index b83bdaa31c7b..a010edc37ee0 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -323,17 +323,15 @@ static const struct bpf_func_proto *bpf_get_probe_write_proto(void)
/*
* Only limited trace_printk() conversion specifiers allowed:
- * %d %i %u %x %ld %li %lu %lx %lld %lli %llu %llx %p %s
+ * %d %i %u %x %ld %li %lu %lx %lld %lli %llu %llx %p %pks %pus %s
*/
BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, u64, arg1,
u64, arg2, u64, arg3)
{
+ int i, mod[3] = {}, fmt_cnt = 0;
+ char buf[64], fmt_ptype;
+ void *unsafe_ptr = NULL;
bool str_seen = false;
- int mod[3] = {};
- int fmt_cnt = 0;
- u64 unsafe_addr;
- char buf[64];
- int i;
/*
* bpf_check()->check_func_arg()->check_stack_boundary()
@@ -359,40 +357,71 @@ BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, u64, arg1,
if (fmt[i] == 'l') {
mod[fmt_cnt]++;
i++;
- } else if (fmt[i] == 'p' || fmt[i] == 's') {
+ } else if (fmt[i] == 'p') {
mod[fmt_cnt]++;
+ if ((fmt[i + 1] == 'k' ||
+ fmt[i + 1] == 'u') &&
+ fmt[i + 2] == 's') {
+ fmt_ptype = fmt[i + 1];
+ i += 2;
+ goto fmt_str;
+ }
+
/* disallow any further format extensions */
if (fmt[i + 1] != 0 &&
!isspace(fmt[i + 1]) &&
!ispunct(fmt[i + 1]))
return -EINVAL;
- fmt_cnt++;
- if (fmt[i] == 's') {
- if (str_seen)
- /* allow only one '%s' per fmt string */
- return -EINVAL;
- str_seen = true;
-
- switch (fmt_cnt) {
- case 1:
- unsafe_addr = arg1;
- arg1 = (long) buf;
- break;
- case 2:
- unsafe_addr = arg2;
- arg2 = (long) buf;
- break;
- case 3:
- unsafe_addr = arg3;
- arg3 = (long) buf;
- break;
- }
- buf[0] = 0;
- strncpy_from_unsafe(buf,
- (void *) (long) unsafe_addr,
+
+ goto fmt_next;
+ } else if (fmt[i] == 's') {
+ mod[fmt_cnt]++;
+ fmt_ptype = fmt[i];
+fmt_str:
+ if (str_seen)
+ /* allow only one '%s' per fmt string */
+ return -EINVAL;
+ str_seen = true;
+
+ if (fmt[i + 1] != 0 &&
+ !isspace(fmt[i + 1]) &&
+ !ispunct(fmt[i + 1]))
+ return -EINVAL;
+
+ switch (fmt_cnt) {
+ case 0:
+ unsafe_ptr = (void *)(long)arg1;
+ arg1 = (long)buf;
+ break;
+ case 1:
+ unsafe_ptr = (void *)(long)arg2;
+ arg2 = (long)buf;
+ break;
+ case 2:
+ unsafe_ptr = (void *)(long)arg3;
+ arg3 = (long)buf;
+ break;
+ }
+
+ buf[0] = 0;
+ switch (fmt_ptype) {
+ case 's':
+#ifdef CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
+ strncpy_from_unsafe(buf, unsafe_ptr,
sizeof(buf));
+ break;
+#endif
+ case 'k':
+ strncpy_from_unsafe_strict(buf, unsafe_ptr,
+ sizeof(buf));
+ break;
+ case 'u':
+ strncpy_from_unsafe_user(buf,
+ (__force void __user *)unsafe_ptr,
+ sizeof(buf));
+ break;
}
- continue;
+ goto fmt_next;
}
if (fmt[i] == 'l') {
@@ -403,6 +432,7 @@ BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, u64, arg1,
if (fmt[i] != 'i' && fmt[i] != 'd' &&
fmt[i] != 'u' && fmt[i] != 'x')
return -EINVAL;
+fmt_next:
fmt_cnt++;
}
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 7c488a1ce318..532b6606a18a 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2168,6 +2168,10 @@ char *fwnode_string(char *buf, char *end, struct fwnode_handle *fwnode,
* f full name
* P node name, including a possible unit address
* - 'x' For printing the address. Equivalent to "%lx".
+ * - '[ku]s' For a BPF/tracing related format specifier, e.g. used out of
+ * bpf_trace_printk() where [ku] prefix specifies either kernel (k)
+ * or user (u) memory to probe, and:
+ * s a string, equivalent to "%s" on direct vsnprintf() use
*
* ** When making changes please also update:
* Documentation/core-api/printk-formats.rst
@@ -2251,6 +2255,14 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
if (!IS_ERR(ptr))
break;
return err_ptr(buf, end, ptr, spec);
+ case 'u':
+ case 'k':
+ switch (fmt[1]) {
+ case 's':
+ return string(buf, end, ptr, spec);
+ default:
+ return error_string(buf, end, "(einval)", spec);
+ }
}
/* default is to _not_ leak addresses, hash before printing */
plane->index is NOT the index of the color plane in a YUV frame.
Actually, a YUV frame is represented by a single drm_plane, even though
it contains three Y, U, V planes.
Cc: stable(a)vger.kernel.org # v5.3
Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
Signed-off-by: Paul Cercueil <paul(a)crapouillou.net>
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 97244462599b..3207105755c9 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -386,7 +386,7 @@ static void ingenic_drm_plane_atomic_update(struct drm_plane *plane,
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
width = state->src_w >> 16;
height = state->src_h >> 16;
- cpp = state->fb->format->cpp[plane->index];
+ cpp = state->fb->format->cpp[0];
priv->dma_hwdesc->addr = addr;
priv->dma_hwdesc->cmd = width * height * cpp / 4;
--
2.26.2
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e
Gitweb: https://git.kernel.org/tip/a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e
Author: Borislav Petkov <bp(a)suse.de>
AuthorDate: Wed, 22 Apr 2020 18:11:30 +02:00
Committer: Borislav Petkov <bp(a)suse.de>
CommitterDate: Fri, 15 May 2020 11:48:01 +02:00
x86: Fix early boot crash on gcc-10, third try
... or the odyssey of trying to disable the stack protector for the
function which generates the stack canary value.
The whole story started with Sergei reporting a boot crash with a kernel
built with gcc-10:
Kernel panic — not syncing: stack-protector: Kernel stack is corrupted in: start_secondary
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.0-rc5—00235—gfffb08b37df9 #139
Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M—D3H, BIOS F12 11/14/2013
Call Trace:
dump_stack
panic
? start_secondary
__stack_chk_fail
start_secondary
secondary_startup_64
-—-[ end Kernel panic — not syncing: stack—protector: Kernel stack is corrupted in: start_secondary
This happens because gcc-10 tail-call optimizes the last function call
in start_secondary() - cpu_startup_entry() - and thus emits a stack
canary check which fails because the canary value changes after the
boot_init_stack_canary() call.
To fix that, the initial attempt was to mark the one function which
generates the stack canary with:
__attribute__((optimize("-fno-stack-protector"))) ... start_secondary(void *unused)
however, using the optimize attribute doesn't work cumulatively
as the attribute does not add to but rather replaces previously
supplied optimization options - roughly all -fxxx options.
The key one among them being -fno-omit-frame-pointer and thus leading to
not present frame pointer - frame pointer which the kernel needs.
The next attempt to prevent compilers from tail-call optimizing
the last function call cpu_startup_entry(), shy of carving out
start_secondary() into a separate compilation unit and building it with
-fno-stack-protector, was to add an empty asm("").
This current solution was short and sweet, and reportedly, is supported
by both compilers but we didn't get very far this time: future (LTO?)
optimization passes could potentially eliminate this, which leads us
to the third attempt: having an actual memory barrier there which the
compiler cannot ignore or move around etc.
That should hold for a long time, but hey we said that about the other
two solutions too so...
Reported-by: Sergei Trofimovich <slyfox(a)gentoo.org>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Tested-by: Kalle Valo <kvalo(a)codeaurora.org>
Cc: <stable(a)vger.kernel.org>
Link: https://lkml.kernel.org/r/20200314164451.346497-1-slyfox@gentoo.org
---
arch/x86/include/asm/stackprotector.h | 7 ++++++-
arch/x86/kernel/smpboot.c | 8 ++++++++
arch/x86/xen/smp_pv.c | 1 +
include/linux/compiler.h | 6 ++++++
init/main.c | 2 ++
5 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/stackprotector.h b/arch/x86/include/asm/stackprotector.h
index 91e29b6..9804a79 100644
--- a/arch/x86/include/asm/stackprotector.h
+++ b/arch/x86/include/asm/stackprotector.h
@@ -55,8 +55,13 @@
/*
* Initialize the stackprotector canary value.
*
- * NOTE: this must only be called from functions that never return,
+ * NOTE: this must only be called from functions that never return
* and it must always be inlined.
+ *
+ * In addition, it should be called from a compilation unit for which
+ * stack protector is disabled. Alternatively, the caller should not end
+ * with a function call which gets tail-call optimized as that would
+ * lead to checking a modified canary value.
*/
static __always_inline void boot_init_stack_canary(void)
{
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 8c89e4d..2f24c33 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -266,6 +266,14 @@ static void notrace start_secondary(void *unused)
wmb();
cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
+
+ /*
+ * Prevent tail call to cpu_startup_entry() because the stack protector
+ * guard has been changed a couple of function calls up, in
+ * boot_init_stack_canary() and must not be checked before tail calling
+ * another function.
+ */
+ prevent_tail_call_optimization();
}
/**
diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 8fb8a50..f2adb63 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -93,6 +93,7 @@ asmlinkage __visible void cpu_bringup_and_idle(void)
cpu_bringup();
boot_init_stack_canary();
cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
+ prevent_tail_call_optimization();
}
void xen_smp_intr_free_pv(unsigned int cpu)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 034b0a6..448c91b 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -356,4 +356,10 @@ static inline void *offset_to_ptr(const int *off)
/* &a[0] degrades to a pointer: a different type from an array */
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
+/*
+ * This is needed in functions which generate the stack canary, see
+ * arch/x86/kernel/smpboot.c::start_secondary() for an example.
+ */
+#define prevent_tail_call_optimization() mb()
+
#endif /* __LINUX_COMPILER_H */
diff --git a/init/main.c b/init/main.c
index 1a5da2c..ad3812b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1036,6 +1036,8 @@ asmlinkage __visible void __init start_kernel(void)
/* Do the rest non-__init'ed, we're now alive */
arch_call_rest_init();
+
+ prevent_tail_call_optimization();
}
/* Call all constructor functions linked into the kernel. */
The GC860 has one GPU device which has a 2d and 3d core. In this case
we want to expose perfmon information for both cores.
The driver has one array which contains all possible perfmon domains
with some meta data - doms_meta. Here we can see that for the GC860
two elements of that array are relevant:
doms_3d: is at index 0 in the doms_meta array with 8 perfmon domains
doms_2d: is at index 1 in the doms_meta array with 1 perfmon domain
The userspace driver wants to get a list of all perfmon domains and
their perfmon signals. This is done by iterating over all domains and
their signals. If the userspace driver wants to access the domain with
id 8 the kernel driver fails and returns invalid data from doms_3d with
and invalid offset.
This results in:
Unable to handle kernel paging request at virtual address 00000000
On such a device it is not possible to use the userspace driver at all.
The fix for this off-by-one error is quite simple.
Reported-by: Paul Cercueil <paul(a)crapouillou.net>
Tested-by: Paul Cercueil <paul(a)crapouillou.net>
Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query infrastructure")
Cc: stable(a)vger.kernel.org
Signed-off-by: Christian Gmeiner <christian.gmeiner(a)gmail.com>
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index e6795bafcbb9..75f9db8f7bec 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain *pm_domain(const struct etnaviv_gpu *gpu,
if (!(gpu->identity.features & meta->feature))
continue;
- if (meta->nr_domains < (index - offset)) {
+ if (index - offset >= meta->nr_domains) {
offset += meta->nr_domains;
continue;
}
--
2.26.2
BZ: 1768622
Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=28587593
commit 8171cd68806bd2fc28ef688e32fb2a3b3deb04e5
Commit 53fafdbb8b21f ("KVM: x86: switch KVMCLOCK base to monotonic raw
clock") changed kvmclock to use tkr_raw instead of tkr_mono. However,
the default kvmclock_offset for the VM was still based on the monotonic
clock and, if the raw clock drifted enough from the monotonic clock,
this could cause a negative system_time to be written to the guest's
struct pvclock. RHEL5 does not like it and (if it boots fast enough to
observe a negative time value) it hangs.
There is another thing to be careful about: getboottime64 returns the
host boot time with tkr_mono frequency, and subtracting the tkr_raw-based
kvmclock value will cause the wallclock to be off if tkr_raw drifts
from tkr_mono. To avoid this, compute the wallclock delta from the
current time instead of being clever and using getboottime64.
Fixes: 53fafdbb8b21f ("KVM: x86: switch KVMCLOCK base to monotonic raw clock")
Cc: stable(a)vger.kernel.org
Reviewed-by: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Index: kernel-rhel/arch/x86/kvm/x86.c
===================================================================
--- kernel-rhel.orig/arch/x86/kvm/x86.c
+++ kernel-rhel/arch/x86/kvm/x86.c
@@ -1595,6 +1595,18 @@ static void update_pvclock_gtod(struct t
write_seqcount_end(&vdata->seq);
}
+
+static s64 get_kvmclock_base_ns(void)
+{
+ /* Count up from boot time, but with the frequency of the raw clock. */
+ return ktime_to_ns(ktime_add(ktime_get_raw(), pvclock_gtod_data.offs_boot));
+}
+#else
+static s64 get_kvmclock_base_ns(void)
+{
+ /* Master clock not used, so we can just use CLOCK_BOOTTIME. */
+ return ktime_get_boottime_ns();
+}
#endif
void kvm_set_pending_timer(struct kvm_vcpu *vcpu)
@@ -1608,7 +1620,7 @@ static void kvm_write_wall_clock(struct
int version;
int r;
struct pvclock_wall_clock wc;
- struct timespec64 boot;
+ u64 wall_nsec;
if (!wall_clock)
return;
@@ -1628,17 +1640,12 @@ static void kvm_write_wall_clock(struct
/*
* The guest calculates current wall clock time by adding
* system time (updated by kvm_guest_time_update below) to the
- * wall clock specified here. guest system time equals host
- * system time for us, thus we must fill in host boot time here.
+ * wall clock specified here. We do the reverse here.
*/
- getboottime64(&boot);
+ wall_nsec = ktime_get_real_ns() - get_kvmclock_ns(kvm);
- if (kvm->arch.kvmclock_offset) {
- struct timespec64 ts = ns_to_timespec64(kvm->arch.kvmclock_offset);
- boot = timespec64_sub(boot, ts);
- }
- wc.sec = (u32)boot.tv_sec; /* overflow in 2106 guest time */
- wc.nsec = boot.tv_nsec;
+ wc.nsec = do_div(wall_nsec, 1000000000);
+ wc.sec = (u32)wall_nsec; /* overflow in 2106 guest time */
wc.version = version;
kvm_write_guest(kvm, wall_clock, &wc, sizeof(wc));
@@ -1886,7 +1893,7 @@ void kvm_write_tsc(struct kvm_vcpu *vcpu
raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
offset = kvm_compute_tsc_offset(vcpu, data);
- ns = ktime_get_boot_ns();
+ ns = get_kvmclock_base_ns();
elapsed = ns - kvm->arch.last_tsc_nsec;
if (vcpu->arch.virtual_tsc_khz) {
@@ -2224,7 +2231,7 @@ u64 get_kvmclock_ns(struct kvm *kvm)
spin_lock(&ka->pvclock_gtod_sync_lock);
if (!ka->use_master_clock) {
spin_unlock(&ka->pvclock_gtod_sync_lock);
- return ktime_get_boot_ns() + ka->kvmclock_offset;
+ return get_kvmclock_base_ns() + ka->kvmclock_offset;
}
hv_clock.tsc_timestamp = ka->master_cycle_now;
@@ -2240,7 +2247,7 @@ u64 get_kvmclock_ns(struct kvm *kvm)
&hv_clock.tsc_to_system_mul);
ret = __pvclock_read_cycles(&hv_clock, rdtsc());
} else
- ret = ktime_get_boot_ns() + ka->kvmclock_offset;
+ ret = get_kvmclock_base_ns() + ka->kvmclock_offset;
put_cpu();
@@ -2339,7 +2346,7 @@ static int kvm_guest_time_update(struct
}
if (!use_master_clock) {
host_tsc = rdtsc();
- kernel_ns = ktime_get_boot_ns();
+ kernel_ns = get_kvmclock_base_ns();
}
tsc_timestamp = kvm_read_l1_tsc(v, host_tsc);
@@ -2379,6 +2386,7 @@ static int kvm_guest_time_update(struct
vcpu->hv_clock.tsc_timestamp = tsc_timestamp;
vcpu->hv_clock.system_time = kernel_ns + v->kvm->arch.kvmclock_offset;
vcpu->last_guest_tsc = tsc_timestamp;
+ WARN_ON(vcpu->hv_clock.system_time < 0);
/* If the host uses TSC clocksource, then it is stable */
pvclock_flags = 0;
@@ -9486,7 +9494,7 @@ int kvm_arch_init_vm(struct kvm *kvm, un
mutex_init(&kvm->arch.apic_map_lock);
spin_lock_init(&kvm->arch.pvclock_gtod_sync_lock);
- kvm->arch.kvmclock_offset = -ktime_get_boot_ns();
+ kvm->arch.kvmclock_offset = -get_kvmclock_base_ns();
pvclock_update_vm_gtod_copy(kvm);
kvm->arch.guest_can_read_msr_platform_info = true;
Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Commit: cdf0854b495e - Makefile: disallow data races on gcc-10 as well
The results of these automated tests are provided below.
Overall result: PASSED
Merge: OK
Compile: OK
Tests: OK
All kernel binaries, config files, and logs are available for download here:
https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=dataware…
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Compile testing
---------------
We compiled the kernel for 4 architectures:
aarch64:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
ppc64le:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
s390x:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
x86_64:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
Hardware testing
----------------
We booted each kernel and ran the following tests:
aarch64:
Host 1:
✅ Boot test
✅ Podman system integration test - as root
✅ Podman system integration test - as user
✅ LTP
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Networking bridge: sanity
✅ Ethernet drivers sanity
✅ Networking socket: fuzz
✅ Networking: igmp conformance test
✅ Networking route: pmtu
✅ Networking route_func - local
✅ Networking route_func - forward
✅ Networking TCP: keepalive test
✅ Networking UDP: socket
✅ Networking tunnel: geneve basic test
✅ Networking tunnel: gre basic
✅ L2TP basic test
✅ Networking tunnel: vxlan basic
✅ Networking ipsec: basic netns - transport
✅ Networking ipsec: basic netns - tunnel
✅ Libkcapi AF_ALG test
✅ ALSA PCM loopback test
✅ ALSA Control (mixer) Userspace Element test
✅ storage: SCSI VPD
🚧 ✅ CIFS Connectathon
🚧 ✅ POSIX pjd-fstest suites
🚧 ✅ jvm - DaCapo Benchmark Suite
🚧 ✅ jvm - jcstress tests
🚧 ✅ Memory function: kaslr
🚧 ✅ audit: audit testsuite test
🚧 ✅ trace: ftrace/tracer
Host 2:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ selinux-policy: serge-testsuite
✅ storage: software RAID testing
✅ stress: stress-ng
🚧 ✅ IPMI driver test
🚧 ✅ IPMItool loop stress test
🚧 ✅ Storage blktests
ppc64le:
Host 1:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
⚡⚡⚡ Boot test
🚧 ⚡⚡⚡ kdump - sysrq-c
Host 2:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
⚡⚡⚡ Boot test
⚡⚡⚡ Podman system integration test - as root
⚡⚡⚡ Podman system integration test - as user
⚡⚡⚡ LTP
⚡⚡⚡ Memory function: memfd_create
⚡⚡⚡ AMTU (Abstract Machine Test Utility)
⚡⚡⚡ Networking bridge: sanity
⚡⚡⚡ Ethernet drivers sanity
⚡⚡⚡ Networking socket: fuzz
⚡⚡⚡ Networking route: pmtu
⚡⚡⚡ Networking route_func - local
⚡⚡⚡ Networking route_func - forward
⚡⚡⚡ Networking TCP: keepalive test
⚡⚡⚡ Networking UDP: socket
⚡⚡⚡ Networking tunnel: geneve basic test
⚡⚡⚡ Networking tunnel: gre basic
⚡⚡⚡ L2TP basic test
⚡⚡⚡ Networking tunnel: vxlan basic
⚡⚡⚡ Networking ipsec: basic netns - tunnel
⚡⚡⚡ Libkcapi AF_ALG test
⚡⚡⚡ ALSA PCM loopback test
⚡⚡⚡ ALSA Control (mixer) Userspace Element test
🚧 ⚡⚡⚡ CIFS Connectathon
🚧 ⚡⚡⚡ POSIX pjd-fstest suites
🚧 ⚡⚡⚡ jvm - DaCapo Benchmark Suite
🚧 ⚡⚡⚡ jvm - jcstress tests
🚧 ⚡⚡⚡ Memory function: kaslr
🚧 ⚡⚡⚡ audit: audit testsuite test
🚧 ⚡⚡⚡ trace: ftrace/tracer
Host 3:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
⚡⚡⚡ Boot test
⚡⚡⚡ xfstests - ext4
⚡⚡⚡ xfstests - xfs
⚡⚡⚡ selinux-policy: serge-testsuite
⚡⚡⚡ storage: software RAID testing
🚧 ⚡⚡⚡ IPMI driver test
🚧 ⚡⚡⚡ IPMItool loop stress test
🚧 ⚡⚡⚡ Storage blktests
Host 4:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
⚡⚡⚡ Boot test
🚧 ⚡⚡⚡ kdump - sysrq-c
s390x:
Host 1:
✅ Boot test
✅ selinux-policy: serge-testsuite
✅ stress: stress-ng
🚧 ✅ Storage blktests
Host 2:
✅ Boot test
🚧 ✅ kdump - sysrq-c
Host 3:
✅ Boot test
✅ Podman system integration test - as root
✅ Podman system integration test - as user
✅ LTP
✅ Memory function: memfd_create
✅ Networking bridge: sanity
✅ Ethernet drivers sanity
✅ Networking route: pmtu
✅ Networking route_func - local
✅ Networking route_func - forward
✅ Networking TCP: keepalive test
✅ Networking UDP: socket
✅ Networking tunnel: geneve basic test
✅ Networking tunnel: gre basic
✅ L2TP basic test
✅ Networking tunnel: vxlan basic
✅ Networking ipsec: basic netns - transport
✅ Networking ipsec: basic netns - tunnel
✅ Libkcapi AF_ALG test
🚧 ✅ CIFS Connectathon
🚧 ✅ POSIX pjd-fstest suites
🚧 ✅ jvm - DaCapo Benchmark Suite
🚧 ✅ jvm - jcstress tests
🚧 ✅ Memory function: kaslr
🚧 ✅ audit: audit testsuite test
🚧 ✅ trace: ftrace/tracer
x86_64:
Host 1:
✅ Boot test
✅ Podman system integration test - as root
✅ Podman system integration test - as user
✅ LTP
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Networking bridge: sanity
✅ Ethernet drivers sanity
✅ Networking socket: fuzz
✅ Networking: igmp conformance test
✅ Networking route: pmtu
✅ Networking route_func - local
✅ Networking route_func - forward
✅ Networking TCP: keepalive test
✅ Networking UDP: socket
✅ Networking tunnel: geneve basic test
✅ Networking tunnel: gre basic
✅ L2TP basic test
✅ Networking tunnel: vxlan basic
✅ Networking ipsec: basic netns - transport
✅ Networking ipsec: basic netns - tunnel
✅ Libkcapi AF_ALG test
✅ pciutils: sanity smoke test
✅ ALSA PCM loopback test
✅ ALSA Control (mixer) Userspace Element test
✅ storage: SCSI VPD
🚧 ✅ CIFS Connectathon
🚧 ✅ POSIX pjd-fstest suites
🚧 ✅ jvm - DaCapo Benchmark Suite
🚧 ✅ jvm - jcstress tests
🚧 ✅ Memory function: kaslr
🚧 ✅ audit: audit testsuite test
🚧 ✅ trace: ftrace/tracer
Host 2:
✅ Boot test
🚧 ✅ kdump - sysrq-c
Host 3:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ selinux-policy: serge-testsuite
✅ storage: software RAID testing
✅ stress: stress-ng
🚧 ✅ IOMMU boot test
🚧 ✅ IPMI driver test
🚧 ✅ IPMItool loop stress test
🚧 ✅ Storage blktests
Test sources: https://github.com/CKI-project/tests-beaker
💚 Pull requests are welcome for new tests or improvements to existing tests!
Aborted tests
-------------
Tests that didn't complete running successfully are marked with ⚡⚡⚡.
If this was caused by an infrastructure issue, we try to mark that
explicitly in the report.
Waived tests
------------
If the test run included waived tests, they are marked with 🚧. Such tests are
executed but their results are not taken into account. Tests are waived when
their results are not reliable enough, e.g. when they're just introduced or are
being fixed.
Testing timeout
---------------
We aim to provide a report within reasonable timeframe. Tests that haven't
finished running yet are marked with ⏱.
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-5.6.y/kernel/v5.6.13-1…
-------------------------------------------------------------------------------
stable-rc/linux-5.6.y boot: 158 boots: 3 failed, 145 passed with 5 offline, 5 untried/unknown (v5.6.13-195-g4dae52cee3fd)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.6.y/kernel/v5.6.…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.6.y/kernel/v5.6.13-195-…
Tree: stable-rc
Branch: linux-5.6.y
Git Describe: v5.6.13-195-g4dae52cee3fd
Git Commit: 4dae52cee3fdd5c174027f69eb44c1876f8837ce
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 100 unique boards, 26 SoC families, 20 builds out of 200
Boot Regressions Detected:
arm:
exynos_defconfig:
gcc-8:
exynos5422-odroidxu3:
lab-collabora: new failure (last pass: v5.6.13)
multi_v7_defconfig:
gcc-8:
sun8i-a83t-bananapi-m3:
lab-clabbe: new failure (last pass: v5.6.13)
versatile_defconfig:
gcc-8:
versatile-pb:
lab-collabora: new failure (last pass: v5.6.13)
Boot Failures Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
multi_v7_defconfig:
gcc-8:
bcm2836-rpi-2-b: 1 failed lab
exynos_defconfig:
gcc-8:
exynos5422-odroidxu3: 1 failed lab
Offline Platforms:
arm:
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
stih410-b2120: 1 offline lab
exynos_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.41-1…
-------------------------------------------------------------------------------
stable-rc/linux-5.4.y boot: 138 boots: 1 failed, 129 passed with 5 offline, 3 untried/unknown (v5.4.41-148-gcac6eb2794c8)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.4.y/kernel/v5.4.41-148-…
Tree: stable-rc
Branch: linux-5.4.y
Git Describe: v5.4.41-148-gcac6eb2794c8
Git Commit: cac6eb2794c85e7777fb0caac6fa75b6364d81a0
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 93 unique boards, 25 SoC families, 21 builds out of 200
Boot Regressions Detected:
arc:
hsdk_defconfig:
gcc-8:
hsdk:
lab-baylibre: new failure (last pass: v5.4.41-2-ged1728340b22)
arm:
qcom_defconfig:
gcc-8:
qcom-apq8064-cm-qs600:
lab-baylibre-seattle: failing since 100 days (last pass: v5.4.17-99-gbd0c6624a110 - first fail: v5.4.17-238-gbffcaa93483d)
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained:
lab-baylibre: failing since 41 days (last pass: v5.4.30-37-g40da5db79b55 - first fail: v5.4.30-39-g23c04177b89f)
arm64:
defconfig:
gcc-8:
sun50i-h6-orangepi-3:
lab-clabbe: new failure (last pass: v5.4.41-2-ged1728340b22)
Boot Failure Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
Offline Platforms:
arm:
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
stih410-b2120: 1 offline lab
exynos_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.12…
-------------------------------------------------------------------------------
stable-rc/linux-4.19.y boot: 118 boots: 1 failed, 108 passed with 5 offline, 4 untried/unknown (v4.19.123-81-gff1170bc0ae9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.123-8…
Tree: stable-rc
Branch: linux-4.19.y
Git Describe: v4.19.123-81-gff1170bc0ae9
Git Commit: ff1170bc0ae95f29422b828165e36382a33b2dd3
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 76 unique boards, 21 SoC families, 20 builds out of 206
Boot Regressions Detected:
arc:
hsdk_defconfig:
gcc-8:
hsdk:
lab-baylibre: failing since 4 days (last pass: v4.19.122-49-g6d5c161fb73d - first fail: v4.19.123-2-gbed44563668d)
arm:
qcom_defconfig:
gcc-8:
qcom-apq8064-cm-qs600:
lab-baylibre-seattle: failing since 6 days (last pass: v4.19.122 - first fail: v4.19.122-48-g92ba0b6b33ad)
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained:
lab-baylibre: failing since 66 days (last pass: v4.19.108-87-g624c124960e8 - first fail: v4.19.109)
Boot Failure Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
Offline Platforms:
arm:
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
stih410-b2120: 1 offline lab
exynos_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
---
For more info write to <info(a)kernelci.org>
When userspace configures KVM_GUESTDBG_SINGLESTEP, KVM will manage the
presence of X86_EFLAGS_TF via kvm_set/get_rflags on vcpus. The actual
rflag bit is therefore hidden from callers.
That includes init_emulate_ctxt() which uses the value returned from
kvm_get_flags() to set ctxt->tf. As a result, x86_emulate_instruction()
will skip a single step, leaving singlestep_rip stale and not returning
to userspace.
This resolves the issue by observing the vcpu guest_debug configuration
alongside ctxt->tf in x86_emulate_instruction(), performing the single
step if set.
Signed-off-by: Felipe Franciosi <felipe(a)nutanix.com>
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c17e6eb9ad43..78463f01c606 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6919,7 +6919,7 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
if (!ctxt->have_exception ||
exception_type(ctxt->exception.vector) == EXCPT_TRAP) {
kvm_rip_write(vcpu, ctxt->eip);
- if (r && ctxt->tf)
+ if ((r && ctxt->tf) || (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP))
r = kvm_vcpu_do_singlestep(vcpu);
if (kvm_x86_ops.update_emulated_instruction)
kvm_x86_ops.update_emulated_instruction(vcpu);
--
2.20.1
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.18…
-------------------------------------------------------------------------------
stable-rc/linux-4.14.y boot: 131 boots: 3 failed, 117 passed with 5 offline, 6 untried/unknown (v4.14.180-115-g53d55a576a17)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.180-1…
Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.180-115-g53d55a576a17
Git Commit: 53d55a576a17377e7713aa3aaeee0f35b06a1f73
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 75 unique boards, 21 SoC families, 18 builds out of 201
Boot Regressions Detected:
arm:
qcom_defconfig:
gcc-8:
qcom-apq8064-cm-qs600:
lab-baylibre-seattle: failing since 5 days (last pass: v4.14.180 - first fail: v4.14.180-37-gad4fc99d1989)
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained:
lab-baylibre: failing since 89 days (last pass: v4.14.170-141-g00a0113414f7 - first fail: v4.14.171-29-g9cfe30e85240)
sunxi_defconfig:
gcc-8:
sun4i-a10-olinuxino-lime:
lab-baylibre: new failure (last pass: v4.14.180-49-g7ab962eff016)
versatile_defconfig:
gcc-8:
versatile-pb:
lab-collabora: new failure (last pass: v4.14.180-49-g7ab962eff016)
Boot Failures Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
arm64:
defconfig:
gcc-8:
meson-gxbb-p200: 1 failed lab
meson-gxm-q200: 1 failed lab
Offline Platforms:
arm:
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
stih410-b2120: 1 offline lab
exynos_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
---
For more info write to <info(a)kernelci.org>
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.223-…
-------------------------------------------------------------------------------
stable-rc/linux-4.4.y boot: 96 boots: 3 failed, 81 passed with 6 offline, 4 untried/unknown, 2 conflicts (v4.4.223-87-g5614224b8432)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.…
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.223-87-…
Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.223-87-g5614224b8432
Git Commit: 5614224b8432edc87094945490727479494da465
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 50 unique boards, 18 SoC families, 17 builds out of 190
Boot Regressions Detected:
arm:
davinci_all_defconfig:
gcc-8:
da850-evm:
lab-baylibre-seattle: new failure (last pass: v4.4.223-36-gceb6b0b3f45d)
dm365evm,legacy:
lab-baylibre-seattle: new failure (last pass: v4.4.223-36-gceb6b0b3f45d)
qcom_defconfig:
gcc-8:
qcom-apq8064-cm-qs600:
lab-baylibre-seattle: failing since 5 days (last pass: v4.4.223 - first fail: v4.4.223-36-g32f5ec9b096d)
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained:
lab-baylibre: failing since 53 days (last pass: v4.4.216-127-g955137020949 - first fail: v4.4.217)
Boot Failures Detected:
arm:
sama5_defconfig:
gcc-8:
at91-sama5d4_xplained: 1 failed lab
imx_v4_v5_defconfig:
gcc-8:
imx27-phytec-phycard-s-rdk: 1 failed lab
multi_v5_defconfig:
gcc-8:
imx27-phytec-phycard-s-rdk: 1 failed lab
Offline Platforms:
arm:
multi_v7_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
davinci_all_defconfig:
gcc-8
da850-evm: 1 offline lab
dm365evm,legacy: 1 offline lab
exynos_defconfig:
gcc-8
exynos5800-peach-pi: 1 offline lab
Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
i386:
i386_defconfig:
qemu_i386:
lab-baylibre: FAIL (gcc-8)
lab-collabora: PASS (gcc-8)
x86_64:
x86_64_defconfig:
qemu_x86_64:
lab-baylibre: FAIL (gcc-8)
lab-collabora: PASS (gcc-8)
---
For more info write to <info(a)kernelci.org>
On Mon, May 18, 2020 at 10:34:34PM +0000, Olsak, Marek wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Greg,
>
> I disagree with this. Bumping the driver version will have implications on other new features, because it's like an ABI barrier exposing new functionality.
And yet another reason why driver versions are a total mess and
shouldn't be in in-kernel drivers :(
Ugh.
I'll go drop this, thanks.
greg k-h