* [PATCH AUTOSEL 5.10 02/16] crypto: ccp - Add a quirk to firmware update
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [Cluster-devel] " Sasha Levin
` (13 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jarkko Sakkinen, Harald Hoyer, Tom Lendacky, Herbert Xu,
Sasha Levin, brijesh.singh, john.allen, davem, linux-crypto
From: Jarkko Sakkinen <jarkko@profian.com>
[ Upstream commit b3b9fdf1a9be4266b01a2063b1f37cdc20806e3b ]
A quirk for fixing the committed TCB version, when upgrading from a
firmware version earlier than 1.50. This is a known issue, and the
documented workaround is to load the firmware twice.
Currently, this issue requires the following workaround:
sudo modprobe -r kvm_amd
sudo modprobe -r ccp
sudo modprobe ccp
sudo modprobe kvm_amd
Implement this workaround inside kernel by checking whether the API
version is less than 1.50, and if so, download the firmware twice.
This addresses the TCB version issue.
Link: https://lore.kernel.org/all/de02389f-249d-f565-1136-4af3655fab2a@profian.com/
Reported-by: Harald Hoyer <harald@profian.com>
Signed-off-by: Jarkko Sakkinen <jarkko@profian.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/ccp/sev-dev.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index ed39a22e1b2b..0ea441e82bf9 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -528,6 +528,11 @@ static int sev_update_firmware(struct device *dev)
struct page *p;
u64 data_size;
+ if (!sev_version_greater_or_equal(0, 15)) {
+ dev_dbg(dev, "DOWNLOAD_FIRMWARE not supported\n");
+ return -1;
+ }
+
if (sev_get_firmware(dev, &firmware) == -ENOENT) {
dev_dbg(dev, "No SEV firmware file present\n");
return -1;
@@ -560,6 +565,14 @@ static int sev_update_firmware(struct device *dev)
data->len = firmware->size;
ret = sev_do_cmd(SEV_CMD_DOWNLOAD_FIRMWARE, data, &error);
+
+ /*
+ * A quirk for fixing the committed TCB version, when upgrading from
+ * earlier firmware version than 1.50.
+ */
+ if (!ret && !sev_version_greater_or_equal(1, 50))
+ ret = sev_do_cmd(SEV_CMD_DOWNLOAD_FIRMWARE, data, &error);
+
if (ret)
dev_dbg(dev, "Failed to update SEV firmware: %#x\n", error);
else
@@ -1074,8 +1087,7 @@ void sev_pci_init(void)
if (sev_get_api_version())
goto err;
- if (sev_version_greater_or_equal(0, 15) &&
- sev_update_firmware(sev->dev) == 0)
+ if (sev_update_firmware(sev->dev) == 0)
sev_get_api_version();
/* Obtain the TMR memory area for SEV-ES use */
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 03/16] gfs2: Switch from strlcpy to strscpy
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [Cluster-devel] " Sasha Levin
` (13 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andreas Gruenbacher, Wolfram Sang, Sasha Levin, rpeterso, cluster-devel
From: Andreas Gruenbacher <agruenba@redhat.com>
[ Upstream commit 204c0300c4e99707e9fb6e57840aa1127060e63f ]
Switch from strlcpy to strscpy and make sure that @count is the size of
the smaller of the source and destination buffers. This prevents
reading beyond the end of the source buffer when the source string isn't
null terminated.
Found by a modified version of syzkaller.
Suggested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/gfs2/ops_fstype.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index b9ed6a6dbcf5..f7ad3e1b26bb 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -381,8 +381,10 @@ static int init_names(struct gfs2_sbd *sdp, int silent)
if (!table[0])
table = sdp->sd_vfs->s_id;
- strlcpy(sdp->sd_proto_name, proto, GFS2_FSNAME_LEN);
- strlcpy(sdp->sd_table_name, table, GFS2_FSNAME_LEN);
+ BUILD_BUG_ON(GFS2_LOCKNAME_LEN > GFS2_FSNAME_LEN);
+
+ strscpy(sdp->sd_proto_name, proto, GFS2_LOCKNAME_LEN);
+ strscpy(sdp->sd_table_name, table, GFS2_LOCKNAME_LEN);
table = sdp->sd_table_name;
while ((table = strchr(table, '/')))
@@ -1414,13 +1416,13 @@ static int gfs2_parse_param(struct fs_context *fc, struct fs_parameter *param)
switch (o) {
case Opt_lockproto:
- strlcpy(args->ar_lockproto, param->string, GFS2_LOCKNAME_LEN);
+ strscpy(args->ar_lockproto, param->string, GFS2_LOCKNAME_LEN);
break;
case Opt_locktable:
- strlcpy(args->ar_locktable, param->string, GFS2_LOCKNAME_LEN);
+ strscpy(args->ar_locktable, param->string, GFS2_LOCKNAME_LEN);
break;
case Opt_hostdata:
- strlcpy(args->ar_hostdata, param->string, GFS2_LOCKNAME_LEN);
+ strscpy(args->ar_hostdata, param->string, GFS2_LOCKNAME_LEN);
break;
case Opt_spectator:
args->ar_spectator = 1;
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [Cluster-devel] [PATCH AUTOSEL 5.10 03/16] gfs2: Switch from strlcpy to strscpy
@ 2022-10-18 0:10 ` Sasha Levin
0 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: cluster-devel.redhat.com
From: Andreas Gruenbacher <agruenba@redhat.com>
[ Upstream commit 204c0300c4e99707e9fb6e57840aa1127060e63f ]
Switch from strlcpy to strscpy and make sure that @count is the size of
the smaller of the source and destination buffers. This prevents
reading beyond the end of the source buffer when the source string isn't
null terminated.
Found by a modified version of syzkaller.
Suggested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/gfs2/ops_fstype.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index b9ed6a6dbcf5..f7ad3e1b26bb 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -381,8 +381,10 @@ static int init_names(struct gfs2_sbd *sdp, int silent)
if (!table[0])
table = sdp->sd_vfs->s_id;
- strlcpy(sdp->sd_proto_name, proto, GFS2_FSNAME_LEN);
- strlcpy(sdp->sd_table_name, table, GFS2_FSNAME_LEN);
+ BUILD_BUG_ON(GFS2_LOCKNAME_LEN > GFS2_FSNAME_LEN);
+
+ strscpy(sdp->sd_proto_name, proto, GFS2_LOCKNAME_LEN);
+ strscpy(sdp->sd_table_name, table, GFS2_LOCKNAME_LEN);
table = sdp->sd_table_name;
while ((table = strchr(table, '/')))
@@ -1414,13 +1416,13 @@ static int gfs2_parse_param(struct fs_context *fc, struct fs_parameter *param)
switch (o) {
case Opt_lockproto:
- strlcpy(args->ar_lockproto, param->string, GFS2_LOCKNAME_LEN);
+ strscpy(args->ar_lockproto, param->string, GFS2_LOCKNAME_LEN);
break;
case Opt_locktable:
- strlcpy(args->ar_locktable, param->string, GFS2_LOCKNAME_LEN);
+ strscpy(args->ar_locktable, param->string, GFS2_LOCKNAME_LEN);
break;
case Opt_hostdata:
- strlcpy(args->ar_hostdata, param->string, GFS2_LOCKNAME_LEN);
+ strscpy(args->ar_hostdata, param->string, GFS2_LOCKNAME_LEN);
break;
case Opt_spectator:
args->ar_spectator = 1;
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 04/16] powerpc/hw_breakpoint: Avoid relying on caller synchronization
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [Cluster-devel] " Sasha Levin
` (13 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Ian Rogers, Marco Elver, Peter Zijlstra,
linuxppc-dev, Dmitry Vyukov
From: Marco Elver <elver@google.com>
[ Upstream commit f95e5a3d59011eec1257d0e76de1e1f8969d426f ]
Internal data structures (cpu_bps, task_bps) of powerpc's hw_breakpoint
implementation have relied on nr_bp_mutex serializing access to them.
Before overhauling synchronization of kernel/events/hw_breakpoint.c,
introduce 2 spinlocks to synchronize cpu_bps and task_bps respectively,
thus avoiding reliance on callers synchronizing powerpc's hw_breakpoint.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20220829124719.675715-10-elver@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/hw_breakpoint.c | 53 ++++++++++++++++++++++-------
1 file changed, 40 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
index f4e8f21046f5..b081e60ecc6a 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -15,6 +15,7 @@
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/smp.h>
+#include <linux/spinlock.h>
#include <linux/debugfs.h>
#include <linux/init.h>
@@ -130,7 +131,14 @@ struct breakpoint {
bool ptrace_bp;
};
+/*
+ * While kernel/events/hw_breakpoint.c does its own synchronization, we cannot
+ * rely on it safely synchronizing internals here; however, we can rely on it
+ * not requesting more breakpoints than available.
+ */
+static DEFINE_SPINLOCK(cpu_bps_lock);
static DEFINE_PER_CPU(struct breakpoint *, cpu_bps[HBP_NUM_MAX]);
+static DEFINE_SPINLOCK(task_bps_lock);
static LIST_HEAD(task_bps);
static struct breakpoint *alloc_breakpoint(struct perf_event *bp)
@@ -175,7 +183,9 @@ static int task_bps_add(struct perf_event *bp)
if (IS_ERR(tmp))
return PTR_ERR(tmp);
+ spin_lock(&task_bps_lock);
list_add(&tmp->list, &task_bps);
+ spin_unlock(&task_bps_lock);
return 0;
}
@@ -183,6 +193,7 @@ static void task_bps_remove(struct perf_event *bp)
{
struct list_head *pos, *q;
+ spin_lock(&task_bps_lock);
list_for_each_safe(pos, q, &task_bps) {
struct breakpoint *tmp = list_entry(pos, struct breakpoint, list);
@@ -192,6 +203,7 @@ static void task_bps_remove(struct perf_event *bp)
break;
}
}
+ spin_unlock(&task_bps_lock);
}
/*
@@ -201,12 +213,17 @@ static void task_bps_remove(struct perf_event *bp)
static bool all_task_bps_check(struct perf_event *bp)
{
struct breakpoint *tmp;
+ bool ret = false;
+ spin_lock(&task_bps_lock);
list_for_each_entry(tmp, &task_bps, list) {
- if (!can_co_exist(tmp, bp))
- return true;
+ if (!can_co_exist(tmp, bp)) {
+ ret = true;
+ break;
+ }
}
- return false;
+ spin_unlock(&task_bps_lock);
+ return ret;
}
/*
@@ -216,13 +233,18 @@ static bool all_task_bps_check(struct perf_event *bp)
static bool same_task_bps_check(struct perf_event *bp)
{
struct breakpoint *tmp;
+ bool ret = false;
+ spin_lock(&task_bps_lock);
list_for_each_entry(tmp, &task_bps, list) {
if (tmp->bp->hw.target == bp->hw.target &&
- !can_co_exist(tmp, bp))
- return true;
+ !can_co_exist(tmp, bp)) {
+ ret = true;
+ break;
+ }
}
- return false;
+ spin_unlock(&task_bps_lock);
+ return ret;
}
static int cpu_bps_add(struct perf_event *bp)
@@ -235,6 +257,7 @@ static int cpu_bps_add(struct perf_event *bp)
if (IS_ERR(tmp))
return PTR_ERR(tmp);
+ spin_lock(&cpu_bps_lock);
cpu_bp = per_cpu_ptr(cpu_bps, bp->cpu);
for (i = 0; i < nr_wp_slots(); i++) {
if (!cpu_bp[i]) {
@@ -242,6 +265,7 @@ static int cpu_bps_add(struct perf_event *bp)
break;
}
}
+ spin_unlock(&cpu_bps_lock);
return 0;
}
@@ -250,6 +274,7 @@ static void cpu_bps_remove(struct perf_event *bp)
struct breakpoint **cpu_bp;
int i = 0;
+ spin_lock(&cpu_bps_lock);
cpu_bp = per_cpu_ptr(cpu_bps, bp->cpu);
for (i = 0; i < nr_wp_slots(); i++) {
if (!cpu_bp[i])
@@ -261,19 +286,25 @@ static void cpu_bps_remove(struct perf_event *bp)
break;
}
}
+ spin_unlock(&cpu_bps_lock);
}
static bool cpu_bps_check(int cpu, struct perf_event *bp)
{
struct breakpoint **cpu_bp;
+ bool ret = false;
int i;
+ spin_lock(&cpu_bps_lock);
cpu_bp = per_cpu_ptr(cpu_bps, cpu);
for (i = 0; i < nr_wp_slots(); i++) {
- if (cpu_bp[i] && !can_co_exist(cpu_bp[i], bp))
- return true;
+ if (cpu_bp[i] && !can_co_exist(cpu_bp[i], bp)) {
+ ret = true;
+ break;
+ }
}
- return false;
+ spin_unlock(&cpu_bps_lock);
+ return ret;
}
static bool all_cpu_bps_check(struct perf_event *bp)
@@ -287,10 +318,6 @@ static bool all_cpu_bps_check(struct perf_event *bp)
return false;
}
-/*
- * We don't use any locks to serialize accesses to cpu_bps or task_bps
- * because are already inside nr_bp_mutex.
- */
int arch_reserve_bp_slot(struct perf_event *bp)
{
int ret;
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 04/16] powerpc/hw_breakpoint: Avoid relying on caller synchronization
@ 2022-10-18 0:10 ` Sasha Levin
0 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Marco Elver, Dmitry Vyukov, Peter Zijlstra, Ian Rogers,
Sasha Levin, mpe, christophe.leroy, linuxppc-dev
From: Marco Elver <elver@google.com>
[ Upstream commit f95e5a3d59011eec1257d0e76de1e1f8969d426f ]
Internal data structures (cpu_bps, task_bps) of powerpc's hw_breakpoint
implementation have relied on nr_bp_mutex serializing access to them.
Before overhauling synchronization of kernel/events/hw_breakpoint.c,
introduce 2 spinlocks to synchronize cpu_bps and task_bps respectively,
thus avoiding reliance on callers synchronizing powerpc's hw_breakpoint.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20220829124719.675715-10-elver@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/hw_breakpoint.c | 53 ++++++++++++++++++++++-------
1 file changed, 40 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
index f4e8f21046f5..b081e60ecc6a 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -15,6 +15,7 @@
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/smp.h>
+#include <linux/spinlock.h>
#include <linux/debugfs.h>
#include <linux/init.h>
@@ -130,7 +131,14 @@ struct breakpoint {
bool ptrace_bp;
};
+/*
+ * While kernel/events/hw_breakpoint.c does its own synchronization, we cannot
+ * rely on it safely synchronizing internals here; however, we can rely on it
+ * not requesting more breakpoints than available.
+ */
+static DEFINE_SPINLOCK(cpu_bps_lock);
static DEFINE_PER_CPU(struct breakpoint *, cpu_bps[HBP_NUM_MAX]);
+static DEFINE_SPINLOCK(task_bps_lock);
static LIST_HEAD(task_bps);
static struct breakpoint *alloc_breakpoint(struct perf_event *bp)
@@ -175,7 +183,9 @@ static int task_bps_add(struct perf_event *bp)
if (IS_ERR(tmp))
return PTR_ERR(tmp);
+ spin_lock(&task_bps_lock);
list_add(&tmp->list, &task_bps);
+ spin_unlock(&task_bps_lock);
return 0;
}
@@ -183,6 +193,7 @@ static void task_bps_remove(struct perf_event *bp)
{
struct list_head *pos, *q;
+ spin_lock(&task_bps_lock);
list_for_each_safe(pos, q, &task_bps) {
struct breakpoint *tmp = list_entry(pos, struct breakpoint, list);
@@ -192,6 +203,7 @@ static void task_bps_remove(struct perf_event *bp)
break;
}
}
+ spin_unlock(&task_bps_lock);
}
/*
@@ -201,12 +213,17 @@ static void task_bps_remove(struct perf_event *bp)
static bool all_task_bps_check(struct perf_event *bp)
{
struct breakpoint *tmp;
+ bool ret = false;
+ spin_lock(&task_bps_lock);
list_for_each_entry(tmp, &task_bps, list) {
- if (!can_co_exist(tmp, bp))
- return true;
+ if (!can_co_exist(tmp, bp)) {
+ ret = true;
+ break;
+ }
}
- return false;
+ spin_unlock(&task_bps_lock);
+ return ret;
}
/*
@@ -216,13 +233,18 @@ static bool all_task_bps_check(struct perf_event *bp)
static bool same_task_bps_check(struct perf_event *bp)
{
struct breakpoint *tmp;
+ bool ret = false;
+ spin_lock(&task_bps_lock);
list_for_each_entry(tmp, &task_bps, list) {
if (tmp->bp->hw.target == bp->hw.target &&
- !can_co_exist(tmp, bp))
- return true;
+ !can_co_exist(tmp, bp)) {
+ ret = true;
+ break;
+ }
}
- return false;
+ spin_unlock(&task_bps_lock);
+ return ret;
}
static int cpu_bps_add(struct perf_event *bp)
@@ -235,6 +257,7 @@ static int cpu_bps_add(struct perf_event *bp)
if (IS_ERR(tmp))
return PTR_ERR(tmp);
+ spin_lock(&cpu_bps_lock);
cpu_bp = per_cpu_ptr(cpu_bps, bp->cpu);
for (i = 0; i < nr_wp_slots(); i++) {
if (!cpu_bp[i]) {
@@ -242,6 +265,7 @@ static int cpu_bps_add(struct perf_event *bp)
break;
}
}
+ spin_unlock(&cpu_bps_lock);
return 0;
}
@@ -250,6 +274,7 @@ static void cpu_bps_remove(struct perf_event *bp)
struct breakpoint **cpu_bp;
int i = 0;
+ spin_lock(&cpu_bps_lock);
cpu_bp = per_cpu_ptr(cpu_bps, bp->cpu);
for (i = 0; i < nr_wp_slots(); i++) {
if (!cpu_bp[i])
@@ -261,19 +286,25 @@ static void cpu_bps_remove(struct perf_event *bp)
break;
}
}
+ spin_unlock(&cpu_bps_lock);
}
static bool cpu_bps_check(int cpu, struct perf_event *bp)
{
struct breakpoint **cpu_bp;
+ bool ret = false;
int i;
+ spin_lock(&cpu_bps_lock);
cpu_bp = per_cpu_ptr(cpu_bps, cpu);
for (i = 0; i < nr_wp_slots(); i++) {
- if (cpu_bp[i] && !can_co_exist(cpu_bp[i], bp))
- return true;
+ if (cpu_bp[i] && !can_co_exist(cpu_bp[i], bp)) {
+ ret = true;
+ break;
+ }
}
- return false;
+ spin_unlock(&cpu_bps_lock);
+ return ret;
}
static bool all_cpu_bps_check(struct perf_event *bp)
@@ -287,10 +318,6 @@ static bool all_cpu_bps_check(struct perf_event *bp)
return false;
}
-/*
- * We don't use any locks to serialize accesses to cpu_bps or task_bps
- * because are already inside nr_bp_mutex.
- */
int arch_reserve_bp_slot(struct perf_event *bp)
{
int ret;
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH AUTOSEL 5.10 04/16] powerpc/hw_breakpoint: Avoid relying on caller synchronization
2022-10-18 0:10 ` Sasha Levin
@ 2022-10-18 9:35 ` Pavel Machek
-1 siblings, 0 replies; 26+ messages in thread
From: Pavel Machek @ 2022-10-18 9:35 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, stable, Marco Elver, Dmitry Vyukov, Peter Zijlstra,
Ian Rogers, mpe, christophe.leroy, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Hi!
> From: Marco Elver <elver@google.com>
>
> [ Upstream commit f95e5a3d59011eec1257d0e76de1e1f8969d426f ]
>
> Internal data structures (cpu_bps, task_bps) of powerpc's hw_breakpoint
> implementation have relied on nr_bp_mutex serializing access to them.
>
> Before overhauling synchronization of kernel/events/hw_breakpoint.c,
> introduce 2 spinlocks to synchronize cpu_bps and task_bps respectively,
> thus avoiding reliance on callers synchronizing powerpc's
> hw_breakpoint.
This is preparation, not a bugfix, not sure why it was picked for
5.10.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH AUTOSEL 5.10 04/16] powerpc/hw_breakpoint: Avoid relying on caller synchronization
@ 2022-10-18 9:35 ` Pavel Machek
0 siblings, 0 replies; 26+ messages in thread
From: Pavel Machek @ 2022-10-18 9:35 UTC (permalink / raw)
To: Sasha Levin
Cc: Ian Rogers, Marco Elver, Peter Zijlstra, linux-kernel, stable,
linuxppc-dev, Dmitry Vyukov
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Hi!
> From: Marco Elver <elver@google.com>
>
> [ Upstream commit f95e5a3d59011eec1257d0e76de1e1f8969d426f ]
>
> Internal data structures (cpu_bps, task_bps) of powerpc's hw_breakpoint
> implementation have relied on nr_bp_mutex serializing access to them.
>
> Before overhauling synchronization of kernel/events/hw_breakpoint.c,
> introduce 2 spinlocks to synchronize cpu_bps and task_bps respectively,
> thus avoiding reliance on callers synchronizing powerpc's
> hw_breakpoint.
This is preparation, not a bugfix, not sure why it was picked for
5.10.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 05/16] cgroup: Remove data-race around cgrp_dfl_visible
@ 2022-10-18 0:10 ` Sasha Levin
0 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Tejun Heo, Abhishek Shah, Gabriel Ryan, Christian Brauner,
Sasha Levin, lizefan.x, hannes, cgroups
From: Tejun Heo <tj@kernel.org>
[ Upstream commit dc79ec1b232ad2c165d381d3dd2626df4ef9b5a4 ]
There's a seemingly harmless data-race around cgrp_dfl_visible detected by
kernel concurrency sanitizer. Let's remove it by throwing WRITE/READ_ONCE at
it.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
Cc: Gabriel Ryan <gabe@cs.columbia.edu>
Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Link: https://lore.kernel.org/netdev/20220819072256.fn7ctciefy4fc4cu@wittgenstein/
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/cgroup/cgroup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 684c16849eff..5178593ee1f1 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -2110,7 +2110,7 @@ static int cgroup_get_tree(struct fs_context *fc)
struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
int ret;
- cgrp_dfl_visible = true;
+ WRITE_ONCE(cgrp_dfl_visible, true);
cgroup_get_live(&cgrp_dfl_root.cgrp);
ctx->root = &cgrp_dfl_root;
@@ -5946,7 +5946,7 @@ int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns,
struct cgroup *cgrp;
int ssid, count = 0;
- if (root == &cgrp_dfl_root && !cgrp_dfl_visible)
+ if (root == &cgrp_dfl_root && !READ_ONCE(cgrp_dfl_visible))
continue;
seq_printf(m, "%d:", root->hierarchy_id);
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 05/16] cgroup: Remove data-race around cgrp_dfl_visible
@ 2022-10-18 0:10 ` Sasha Levin
0 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA, stable-u79uwXL29TY76Z2rM5mHXA
Cc: Tejun Heo, Abhishek Shah, Gabriel Ryan, Christian Brauner,
Sasha Levin, lizefan.x-EC8Uxl6Npydl57MIdRCFDg,
hannes-druUgvl0LCNAfugRpC6u6w, cgroups-u79uwXL29TY76Z2rM5mHXA
From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[ Upstream commit dc79ec1b232ad2c165d381d3dd2626df4ef9b5a4 ]
There's a seemingly harmless data-race around cgrp_dfl_visible detected by
kernel concurrency sanitizer. Let's remove it by throwing WRITE/READ_ONCE at
it.
Signed-off-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reported-by: Abhishek Shah <abhishek.shah-WLbs8XpHrcb2fBVCVOL8/A@public.gmane.org>
Cc: Gabriel Ryan <gabe-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Reviewed-by: Christian Brauner (Microsoft) <brauner-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Link: https://lore.kernel.org/netdev/20220819072256.fn7ctciefy4fc4cu@wittgenstein/
Signed-off-by: Sasha Levin <sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
kernel/cgroup/cgroup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 684c16849eff..5178593ee1f1 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -2110,7 +2110,7 @@ static int cgroup_get_tree(struct fs_context *fc)
struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
int ret;
- cgrp_dfl_visible = true;
+ WRITE_ONCE(cgrp_dfl_visible, true);
cgroup_get_live(&cgrp_dfl_root.cgrp);
ctx->root = &cgrp_dfl_root;
@@ -5946,7 +5946,7 @@ int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns,
struct cgroup *cgrp;
int ssid, count = 0;
- if (root == &cgrp_dfl_root && !cgrp_dfl_visible)
+ if (root == &cgrp_dfl_root && !READ_ONCE(cgrp_dfl_visible))
continue;
seq_printf(m, "%d:", root->hierarchy_id);
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 06/16] of/fdt: Don't calculate initrd size from DT if start > end
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
` (3 preceding siblings ...)
2022-10-18 0:10 ` Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 07/16] objtool,x86: Teach decode about LOOP* instructions Sasha Levin
` (9 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Marek Bykowski, Rob Herring, Sasha Levin, robh+dt, frowand.list,
devicetree
From: Marek Bykowski <marek.bykowski@gmail.com>
[ Upstream commit d5e3050c0feb8bf7b9a75482fafcc31b90257926 ]
If the properties 'linux,initrd-start' and 'linux,initrd-end' of
the chosen node populated from the bootloader, eg. U-Boot, are so that
start > end, then the phys_initrd_size calculated from end - start is
negative that subsequently gets converted to a high positive value for
being unsigned long long. Then, the memory region with the (invalid)
size is added to the bootmem and attempted being paged in paging_init()
that results in the kernel fault.
For example, on the FVP ARM64 system I'm running, the U-Boot populates
the 'linux,initrd-start' with 8800_0000 and 'linux,initrd-end' with 0.
The phys_initrd_size calculated is then ffff_ffff_7800_0000
(= 0 - 8800_0000 = -8800_0000 + ULLONG_MAX + 1). paging_init() then
attempts to map the address 8800_0000 + ffff_ffff_7800_0000 and oops'es
as below.
It should be stressed, it is generally a fault of the bootloader's with
the kernel relying on it, however we should not allow the bootloader's
misconfiguration to lead to the kernel oops. Not only the kernel should be
bullet proof against it but also finding the root cause of the paging
fault spanning over the bootloader, DT, and kernel may happen is not so
easy.
Unable to handle kernel paging request at virtual address fffffffefe43c000
Mem abort info:
ESR = 0x96000007
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000007
CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000
[fffffffefe43c000] pgd=0000000080de9003, pud=0000000080de9003
Unable to handle kernel paging request at virtual address ffffff8000de9f90
Mem abort info:
ESR = 0x96000005
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000005
CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000
[ffffff8000de9f90] pgd=0000000000000000, pud=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.51-yocto-standard #1
Hardware name: FVP Base (DT)
pstate: 60000085 (nZCv daIf -PAN -UAO)
pc : show_pte+0x12c/0x1b4
lr : show_pte+0x100/0x1b4
sp : ffffffc010ce3b30
x29: ffffffc010ce3b30 x28: ffffffc010ceed80
x27: fffffffefe43c000 x26: fffffffefe43a028
x25: 0000000080bf0000 x24: 0000000000000025
x23: ffffffc010b8d000 x22: ffffffc010e3d000
x23: ffffffc010b8d000 x22: ffffffc010e3d000
x21: 0000000080de9000 x20: ffffff7f80000f90
x19: fffffffefe43c000 x18: 0000000000000030
x17: 0000000000001400 x16: 0000000000001c00
x15: ffffffc010cef1b8 x14: ffffffffffffffff
x13: ffffffc010df1f40 x12: ffffffc010df1b70
x11: ffffffc010ce3b30 x10: ffffffc010ce3b30
x9 : 00000000ffffffc8 x8 : 0000000000000000
x7 : 000000000000000f x6 : ffffffc010df16e8
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000ffffffff x2 : 0000000000000000
x1 : 0000008080000000 x0 : ffffffc010af1d68
Call trace:
show_pte+0x12c/0x1b4
die_kernel_fault+0x54/0x78
__do_kernel_fault+0x11c/0x128
do_translation_fault+0x58/0xac
do_mem_abort+0x50/0xb0
el1_da+0x1c/0x90
__create_pgd_mapping+0x348/0x598
paging_init+0x3f0/0x70d0
setup_arch+0x2c0/0x5d4
start_kernel+0x94/0x49c
Code: 92748eb5 900052a0 9135a000 cb010294 (f8756a96)
Signed-off-by: Marek Bykowski <marek.bykowski@gmail.com>
Link: https://lore.kernel.org/r/20220909023358.76881-1-marek.bykowski@gmail.com
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/of/fdt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 5a1b8688b460..b54fe601370b 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -885,6 +885,8 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
if (!prop)
return;
end = of_read_number(prop, len/4);
+ if (start > end)
+ return;
__early_init_dt_declare_initrd(start, end);
phys_initrd_start = start;
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 07/16] objtool,x86: Teach decode about LOOP* instructions
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
` (4 preceding siblings ...)
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 06/16] of/fdt: Don't calculate initrd size from DT if start > end Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [Cluster-devel] " Sasha Levin
` (8 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Peter Zijlstra, Masami Hiramatsu, Sasha Levin, jpoimboe, bp,
fenghua.yu, tony.luck
From: Peter Zijlstra <peterz@infradead.org>
[ Upstream commit 7a7621dfa417aa3715d2a3bd1bdd6cf5018274d0 ]
When 'discussing' control flow Masami mentioned the LOOP* instructions
and I realized objtool doesn't decode them properly.
As it turns out, these instructions are somewhat inefficient and as
such unlikely to be emitted by the compiler (a few vmlinux.o checks
can't find a single one) so this isn't critical, but still, best to
decode them properly.
Reported-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/Yxhd4EMKyoFoH9y4@hirez.programming.kicks-ass.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/objtool/arch/x86/decode.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index d8f47704fd85..c804b0b4215b 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -501,6 +501,12 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec,
*type = INSN_CONTEXT_SWITCH;
break;
+ case 0xe0: /* loopne */
+ case 0xe1: /* loope */
+ case 0xe2: /* loop */
+ *type = INSN_JUMP_CONDITIONAL;
+ break;
+
case 0xe8:
*type = INSN_CALL;
/*
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 08/16] gfs2: Check sb_bsize_shift after reading superblock
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [Cluster-devel] " Sasha Levin
` (13 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andrew Price, syzbot+dcf33a7aae997956fe06, Andreas Gruenbacher,
Sasha Levin, rpeterso, cluster-devel
From: Andrew Price <anprice@redhat.com>
[ Upstream commit 670f8ce56dd0632dc29a0322e188cc73ce3c6b92 ]
Fuzzers like to scribble over sb_bsize_shift but in reality it's very
unlikely that this field would be corrupted on its own. Nevertheless it
should be checked to avoid the possibility of messy mount errors due to
bad calculations. It's always a fixed value based on the block size so
we can just check that it's the expected value.
Tested with:
mkfs.gfs2 -O -p lock_nolock /dev/vdb
for i in 0 -1 64 65 32 33; do
gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb
mount /dev/vdb /mnt/test && umount /mnt/test
done
Before this patch we get a withdraw after
[ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block
[ 76.413681] bh = 19 (type: exp=5, found=4)
[ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492
and with UBSAN configured we also get complaints like
[ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19
[ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int'
After the patch, these complaints don't appear, mount fails immediately
and we get an explanation in dmesg.
Reported-by: syzbot+dcf33a7aae997956fe06@syzkaller.appspotmail.com
Signed-off-by: Andrew Price <anprice@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/gfs2/ops_fstype.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index f7ad3e1b26bb..648f7336043f 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -182,7 +182,10 @@ static int gfs2_check_sb(struct gfs2_sbd *sdp, int silent)
pr_warn("Invalid superblock size\n");
return -EINVAL;
}
-
+ if (sb->sb_bsize_shift != ffs(sb->sb_bsize) - 1) {
+ pr_warn("Invalid block size shift\n");
+ return -EINVAL;
+ }
return 0;
}
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [Cluster-devel] [PATCH AUTOSEL 5.10 08/16] gfs2: Check sb_bsize_shift after reading superblock
@ 2022-10-18 0:10 ` Sasha Levin
0 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: cluster-devel.redhat.com
From: Andrew Price <anprice@redhat.com>
[ Upstream commit 670f8ce56dd0632dc29a0322e188cc73ce3c6b92 ]
Fuzzers like to scribble over sb_bsize_shift but in reality it's very
unlikely that this field would be corrupted on its own. Nevertheless it
should be checked to avoid the possibility of messy mount errors due to
bad calculations. It's always a fixed value based on the block size so
we can just check that it's the expected value.
Tested with:
mkfs.gfs2 -O -p lock_nolock /dev/vdb
for i in 0 -1 64 65 32 33; do
gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb
mount /dev/vdb /mnt/test && umount /mnt/test
done
Before this patch we get a withdraw after
[ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block
[ 76.413681] bh = 19 (type: exp=5, found=4)
[ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492
and with UBSAN configured we also get complaints like
[ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19
[ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int'
After the patch, these complaints don't appear, mount fails immediately
and we get an explanation in dmesg.
Reported-by: syzbot+dcf33a7aae997956fe06 at syzkaller.appspotmail.com
Signed-off-by: Andrew Price <anprice@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/gfs2/ops_fstype.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index f7ad3e1b26bb..648f7336043f 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -182,7 +182,10 @@ static int gfs2_check_sb(struct gfs2_sbd *sdp, int silent)
pr_warn("Invalid superblock size\n");
return -EINVAL;
}
-
+ if (sb->sb_bsize_shift != ffs(sb->sb_bsize) - 1) {
+ pr_warn("Invalid block size shift\n");
+ return -EINVAL;
+ }
return 0;
}
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 09/16] powerpc/64: don't refer nr_cpu_ids in asm code when it's undefined
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [Cluster-devel] " Sasha Levin
` (13 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Stephen Rothwell, Yury Norov, aik, amodra,
linuxppc-dev, dja
From: Yury Norov <yury.norov@gmail.com>
[ Upstream commit 546a073d628111e3338af689938407e77d5dc38f ]
generic_secondary_common_init() calls LOAD_REG_ADDR(r7, nr_cpu_ids)
conditionally on CONFIG_SMP. However, if 'NR_CPUS == 1', kernel doesn't
use the nr_cpu_ids, and in C code, it's just:
#if NR_CPUS == 1
#define nr_cpu_ids
...
This series makes declaration of nr_cpu_ids conditional on NR_CPUS == 1,
and that reveals the issue, because compiler can't link the
LOAD_REG_ADDR(r7, nr_cpu_ids) against nonexisting symbol.
Current code looks unsafe for those who build kernel with CONFIG_SMP=y and
NR_CPUS == 1. This is weird configuration, but not disallowed.
Fix the linker error by replacing LOAD_REG_ADDR() with LOAD_REG_IMMEDIATE()
conditionally on NR_CPUS == 1.
As the following patch adds CONFIG_FORCE_NR_CPUS option that has the
similar effect on nr_cpu_ids, make the generic_secondary_common_init()
conditional on it too.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/head_64.S | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 2d6581db0c7b..86f9970d8631 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -392,8 +392,12 @@ generic_secondary_common_init:
#else
LOAD_REG_ADDR(r8, paca_ptrs) /* Load paca_ptrs pointe */
ld r8,0(r8) /* Get base vaddr of array */
+#if (NR_CPUS == 1) || defined(CONFIG_FORCE_NR_CPUS)
+ LOAD_REG_IMMEDIATE(r7, NR_CPUS)
+#else
LOAD_REG_ADDR(r7, nr_cpu_ids) /* Load nr_cpu_ids address */
lwz r7,0(r7) /* also the max paca allocated */
+#endif
li r5,0 /* logical cpu id */
1:
sldi r9,r5,3 /* get paca_ptrs[] index from cpu id */
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 09/16] powerpc/64: don't refer nr_cpu_ids in asm code when it's undefined
@ 2022-10-18 0:10 ` Sasha Levin
0 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Yury Norov, Stephen Rothwell, Sasha Levin, mpe, aik,
christophe.leroy, dja, amodra, linuxppc-dev
From: Yury Norov <yury.norov@gmail.com>
[ Upstream commit 546a073d628111e3338af689938407e77d5dc38f ]
generic_secondary_common_init() calls LOAD_REG_ADDR(r7, nr_cpu_ids)
conditionally on CONFIG_SMP. However, if 'NR_CPUS == 1', kernel doesn't
use the nr_cpu_ids, and in C code, it's just:
#if NR_CPUS == 1
#define nr_cpu_ids
...
This series makes declaration of nr_cpu_ids conditional on NR_CPUS == 1,
and that reveals the issue, because compiler can't link the
LOAD_REG_ADDR(r7, nr_cpu_ids) against nonexisting symbol.
Current code looks unsafe for those who build kernel with CONFIG_SMP=y and
NR_CPUS == 1. This is weird configuration, but not disallowed.
Fix the linker error by replacing LOAD_REG_ADDR() with LOAD_REG_IMMEDIATE()
conditionally on NR_CPUS == 1.
As the following patch adds CONFIG_FORCE_NR_CPUS option that has the
similar effect on nr_cpu_ids, make the generic_secondary_common_init()
conditional on it too.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/head_64.S | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 2d6581db0c7b..86f9970d8631 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -392,8 +392,12 @@ generic_secondary_common_init:
#else
LOAD_REG_ADDR(r8, paca_ptrs) /* Load paca_ptrs pointe */
ld r8,0(r8) /* Get base vaddr of array */
+#if (NR_CPUS == 1) || defined(CONFIG_FORCE_NR_CPUS)
+ LOAD_REG_IMMEDIATE(r7, NR_CPUS)
+#else
LOAD_REG_ADDR(r7, nr_cpu_ids) /* Load nr_cpu_ids address */
lwz r7,0(r7) /* also the max paca allocated */
+#endif
li r5,0 /* logical cpu id */
1:
sldi r9,r5,3 /* get paca_ptrs[] index from cpu id */
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 10/16] m68knommu: fix non-specific 68328 choice interrupt build failure
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
` (7 preceding siblings ...)
2022-10-18 0:10 ` Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 11/16] m68knommu: fix non-mmu classic 68000 legacy timer tick selection Sasha Levin
` (5 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Greg Ungerer, kernel test robot, Geert Uytterhoeven, Sasha Levin,
linux-m68k
From: Greg Ungerer <gerg@linux-m68k.org>
[ Upstream commit 750321ace9107e103f254bf46900629ff347eb7b ]
Compiling for a classic m68k non-MMU target with no specific CPU
selected fails with the following error:
arch/m68k/68000/ints.c: In function 'process_int':
>> arch/m68k/68000/ints.c:82:30: error: 'ISR' undeclared (first use in this function)
82 | unsigned long pend = ISR;
| ^~~
This interrupt handling code is specific to the 68328 family of 68000
parts. There is a couple of variants (68EZ328, 68VZ328) and the common
ancestor of them the strait 68328.
The code here includes a specific header for each variant type. But if
none is selected then nothing is included to supply the appropriate
register and bit flags defines.
Rearrange the includes so that at least one type is always included.
At the very least the 68328 base type should be the fallback, so make
that true.
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/m68k/68000/ints.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/m68k/68000/ints.c b/arch/m68k/68000/ints.c
index cda49b12d7be..f9a5ec781408 100644
--- a/arch/m68k/68000/ints.c
+++ b/arch/m68k/68000/ints.c
@@ -18,12 +18,12 @@
#include <asm/io.h>
#include <asm/machdep.h>
-#if defined(CONFIG_M68328)
-#include <asm/MC68328.h>
-#elif defined(CONFIG_M68EZ328)
+#if defined(CONFIG_M68EZ328)
#include <asm/MC68EZ328.h>
#elif defined(CONFIG_M68VZ328)
#include <asm/MC68VZ328.h>
+#else
+#include <asm/MC68328.h>
#endif
/* assembler routines */
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 11/16] m68knommu: fix non-mmu classic 68000 legacy timer tick selection
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
` (8 preceding siblings ...)
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 10/16] m68knommu: fix non-specific 68328 choice interrupt build failure Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 12/16] of: Fix "dma-ranges" handling for bus controllers Sasha Levin
` (4 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Greg Ungerer, Geert Uytterhoeven, Sasha Levin, linux-m68k
From: Greg Ungerer <gerg@linux-m68k.org>
[ Upstream commit 18011e50c497f04a57a8e00122906f04922b30b4 ]
The family of classic 68000 parts supported when in non-mmu mode all
currently use the legacy timer support. Move the selection of that config
option, LEGACY_TIMER_TICK, into the core CPU configuration.
This fixes compilation if no specific CPU variant is selected, since
the LEGACY_TIMER_TICK option was only selected in the specific CPU
variant configurations.
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/m68k/Kconfig.cpu | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 936cd9619bf0..927df820da78 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -45,6 +45,7 @@ config M68000
select GENERIC_CSUM
select CPU_NO_EFFICIENT_FFS
select HAVE_ARCH_HASH
+ select LEGACY_TIMER_TICK
help
The Freescale (was Motorola) 68000 CPU is the first generation of
the well known M68K family of processors. The CPU core as well as
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 12/16] of: Fix "dma-ranges" handling for bus controllers
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
` (9 preceding siblings ...)
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 11/16] m68knommu: fix non-mmu classic 68000 legacy timer tick selection Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-20 13:19 ` Rob Herring
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 13/16] kmsan: disable physical page merging in biovec Sasha Levin
` (3 subsequent siblings)
14 siblings, 1 reply; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Robin Murphy, Serge Semin, Rob Herring, Sasha Levin, robh+dt,
frowand.list, devicetree
From: Robin Murphy <robin.murphy@arm.com>
[ Upstream commit f1ad5338a4d57fe1fe6475003acb8c70bf9d1bdf ]
Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes")
relaxed the handling of "dma-ranges" for any leaf node on the assumption
that it would still represent a usage error for the property to be
present on a non-bus leaf node. However there turns out to be a fiddly
case where a bus also represents a DMA-capable device in its own right,
such as a PCIe root complex with an integrated DMA engine on its
platform side. In such cases, "dma-ranges" translation is entirely valid
for devices discovered behind the bus, but should not be erroneously
applied to the bus controller device itself which operates in its
parent's address space. Fix this by restoring the previous behaviour for
the specific case where a device is configured via its own OF node,
since it is logical to assume that a device should never represent its
own parent bus.
Reported-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/112e8f3d3e7c054ecf5e12b5ac0aa5596ec00681.1664455433.git.robin.murphy@arm.com
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/of/address.c | 4 +++-
drivers/of/device.c | 9 ++++++++-
drivers/of/of_private.h | 5 +++++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 73ddf2540f3f..fdacf6c3c91f 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -626,7 +626,8 @@ u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
}
EXPORT_SYMBOL(of_translate_address);
-static struct device_node *__of_get_dma_parent(const struct device_node *np)
+#ifdef CONFIG_HAS_DMA
+struct device_node *__of_get_dma_parent(const struct device_node *np)
{
struct of_phandle_args args;
int ret, index;
@@ -643,6 +644,7 @@ static struct device_node *__of_get_dma_parent(const struct device_node *np)
return of_node_get(args.np);
}
+#endif
static struct device_node *of_get_next_dma_parent(struct device_node *np)
{
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 1122daa8e273..f760199abda6 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -93,12 +93,19 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
{
const struct iommu_ops *iommu;
const struct bus_dma_region *map = NULL;
+ struct device_node *bus_np;
u64 dma_start = 0;
u64 mask, end, size = 0;
bool coherent;
int ret;
- ret = of_dma_get_range(np, &map);
+ if (np == dev->of_node)
+ bus_np = __of_get_dma_parent(np);
+ else
+ bus_np = of_node_get(np);
+
+ ret = of_dma_get_range(bus_np, &map);
+ of_node_put(bus_np);
if (ret < 0) {
/*
* For legacy reasons, we have to assume some devices need
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index d9e6a324de0a..ffc2099935f5 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -161,12 +161,17 @@ struct bus_dma_region;
#if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_HAS_DMA)
int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map);
+struct device_node *__of_get_dma_parent(const struct device_node *np);
#else
static inline int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map)
{
return -ENODEV;
}
+static inline struct device_node *__of_get_dma_parent(const struct device_node *np)
+{
+ return of_get_parent(np);
+}
#endif
#endif /* _LINUX_OF_PRIVATE_H */
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 13/16] kmsan: disable physical page merging in biovec
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
` (10 preceding siblings ...)
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 12/16] of: Fix "dma-ranges" handling for bus controllers Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 9:34 ` Pavel Machek
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 14/16] 9p: trans_fd/p9_conn_cancel: drop client lock earlier Sasha Levin
` (2 subsequent siblings)
14 siblings, 1 reply; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexander Potapenko, Alexander Viro, Alexei Starovoitov,
Andrey Konovalov, Andrey Konovalov, Andy Lutomirski,
Arnd Bergmann, Borislav Petkov, Christoph Hellwig,
Christoph Lameter, David Rientjes, Dmitry Vyukov, Eric Biggers,
Eric Biggers, Eric Dumazet, Greg Kroah-Hartman, Herbert Xu,
Ilya Leoshkevich, Ingo Molnar, Jens Axboe, Joonsoo Kim,
Kees Cook, Marco Elver, Mark Rutland, Matthew Wilcox,
Michael S . Tsirkin, Pekka Enberg, Peter Zijlstra, Petr Mladek,
Stephen Rothwell, Steven Rostedt, Thomas Gleixner, Vasily Gorbik,
Vegard Nossum, Vlastimil Babka, Andrew Morton, Sasha Levin,
linux-block
From: Alexander Potapenko <glider@google.com>
[ Upstream commit f630a5d0ca59a6e73b61e3f82c371dc230da99ff ]
KMSAN metadata for adjacent physical pages may not be adjacent, therefore
accessing such pages together may lead to metadata corruption. We disable
merging pages in biovec to prevent such corruptions.
Link: https://lkml.kernel.org/r/20220915150417.722975-28-glider@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Eric Biggers <ebiggers@google.com>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Marco Elver <elver@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
block/blk.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/block/blk.h b/block/blk.h
index 997941cd999f..107db0011d4c 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -59,6 +59,13 @@ static inline bool biovec_phys_mergeable(struct request_queue *q,
phys_addr_t addr1 = page_to_phys(vec1->bv_page) + vec1->bv_offset;
phys_addr_t addr2 = page_to_phys(vec2->bv_page) + vec2->bv_offset;
+ /*
+ * Merging adjacent physical pages may not work correctly under KMSAN
+ * if their metadata pages aren't adjacent. Just disable merging.
+ */
+ if (IS_ENABLED(CONFIG_KMSAN))
+ return false;
+
if (addr1 + vec1->bv_len != addr2)
return false;
if (xen_domain() && !xen_biovec_phys_mergeable(vec1, vec2->bv_page))
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH AUTOSEL 5.10 13/16] kmsan: disable physical page merging in biovec
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 13/16] kmsan: disable physical page merging in biovec Sasha Levin
@ 2022-10-18 9:34 ` Pavel Machek
0 siblings, 0 replies; 26+ messages in thread
From: Pavel Machek @ 2022-10-18 9:34 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, stable, Alexander Potapenko, Alexander Viro,
Alexei Starovoitov, Andrey Konovalov, Andrey Konovalov,
Andy Lutomirski, Arnd Bergmann, Borislav Petkov,
Christoph Hellwig, Christoph Lameter, David Rientjes,
Dmitry Vyukov, Eric Biggers, Eric Biggers, Eric Dumazet,
Greg Kroah-Hartman, Herbert Xu, Ilya Leoshkevich, Ingo Molnar,
Jens Axboe, Joonsoo Kim, Kees Cook, Marco Elver, Mark Rutland,
Matthew Wilcox, Michael S . Tsirkin, Pekka Enberg,
Peter Zijlstra, Petr Mladek, Stephen Rothwell, Steven Rostedt,
Thomas Gleixner, Vasily Gorbik, Vegard Nossum, Vlastimil Babka,
Andrew Morton, linux-block
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
Hi!
> From: Alexander Potapenko <glider@google.com>
>
> [ Upstream commit f630a5d0ca59a6e73b61e3f82c371dc230da99ff ]
>
> KMSAN metadata for adjacent physical pages may not be adjacent, therefore
> accessing such pages together may lead to metadata corruption. We disable
> merging pages in biovec to prevent such corruptions.
KMSAN is not there at least in 5.10, so we should not have this in
-stable.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 14/16] 9p: trans_fd/p9_conn_cancel: drop client lock earlier
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
` (11 preceding siblings ...)
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 13/16] kmsan: disable physical page merging in biovec Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 15/16] 9p/trans_fd: always use O_NONBLOCK read/write Sasha Levin
2022-10-18 0:10 ` Sasha Levin
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dominique Martinet, syzbot+50f7e8d06c3768dd97f3, Schspa Shi,
Sasha Levin, ericvh, lucho, davem, edumazet, kuba, pabeni,
v9fs-developer, netdev
From: Dominique Martinet <asmadeus@codewreck.org>
[ Upstream commit 52f1c45dde9136f964d63a77d19826c8a74e2c7f ]
syzbot reported a double-lock here and we no longer need this
lock after requests have been moved off to local list:
just drop the lock earlier.
Link: https://lkml.kernel.org/r/20220904064028.1305220-1-asmadeus@codewreck.org
Reported-by: syzbot+50f7e8d06c3768dd97f3@syzkaller.appspotmail.com
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Tested-by: Schspa Shi <schspa@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/9p/trans_fd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 8f528e783a6c..c4096b14d159 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -205,6 +205,8 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
list_move(&req->req_list, &cancel_list);
}
+ spin_unlock(&m->client->lock);
+
list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
list_del(&req->req_list);
@@ -212,7 +214,6 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
req->t_err = err;
p9_client_cb(m->client, req, REQ_STATUS_ERROR);
}
- spin_unlock(&m->client->lock);
}
static __poll_t
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 15/16] 9p/trans_fd: always use O_NONBLOCK read/write
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
` (12 preceding siblings ...)
2022-10-18 0:10 ` [PATCH AUTOSEL 5.10 14/16] 9p: trans_fd/p9_conn_cancel: drop client lock earlier Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` Sasha Levin
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Tetsuo Handa, syzbot, Christian Schoenebeck, Dominique Martinet,
Sasha Levin, ericvh, lucho, davem, edumazet, kuba, pabeni,
v9fs-developer, netdev
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
[ Upstream commit ef575281b21e9a34dfae544a187c6aac2ae424a9 ]
syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop()
from p9_conn_destroy() from p9_fd_close() is failing to interrupt already
started kernel_read() from p9_fd_read() from p9_read_work() and/or
kernel_write() from p9_fd_write() from p9_write_work() requests.
Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not
need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open()
does not set O_NONBLOCK flag, but pipe blocks unless signal is pending,
p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when
the file descriptor refers to a pipe. In other words, pipe file descriptor
needs to be handled as if socket file descriptor.
We somehow need to interrupt kernel_read()/kernel_write() on pipes.
A minimal change, which this patch is doing, is to set O_NONBLOCK flag
from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing
of regular files. But this approach changes O_NONBLOCK flag on userspace-
supplied file descriptors (which might break userspace programs), and
O_NONBLOCK flag could be changed by userspace. It would be possible to set
O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still
remains small race window for clearing O_NONBLOCK flag.
If we don't want to manipulate O_NONBLOCK flag, we might be able to
surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING)
and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are
processed by kernel threads which process global system_wq workqueue,
signals could not be delivered from remote threads when p9_mux_poll_stop()
from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling
set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be
needed if we count on signals for making kernel_read()/kernel_write()
non-blocking.
Link: https://lkml.kernel.org/r/345de429-a88b-7097-d177-adecf9fed342@I-love.SAKURA.ne.jp
Link: https://syzkaller.appspot.com/bug?extid=8b41a1365f1106fd0f33 [1]
Reported-by: syzbot <syzbot+8b41a1365f1106fd0f33@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: syzbot <syzbot+8b41a1365f1106fd0f33@syzkaller.appspotmail.com>
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
[Dominique: add comment at Christian's suggestion]
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/9p/trans_fd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index c4096b14d159..fec6c800c898 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -821,11 +821,14 @@ static int p9_fd_open(struct p9_client *client, int rfd, int wfd)
goto out_free_ts;
if (!(ts->rd->f_mode & FMODE_READ))
goto out_put_rd;
+ /* prevent workers from hanging on IO when fd is a pipe */
+ ts->rd->f_flags |= O_NONBLOCK;
ts->wr = fget(wfd);
if (!ts->wr)
goto out_put_rd;
if (!(ts->wr->f_mode & FMODE_WRITE))
goto out_put_wr;
+ ts->wr->f_flags |= O_NONBLOCK;
client->trans = ts;
client->status = Connected;
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 16/16] virtio_pci: don't try to use intxif pin is zero
2022-10-18 0:10 [PATCH AUTOSEL 5.10 01/16] crypto: qcom-rng - Fix qcom_rng_of_match unused warning Sasha Levin
@ 2022-10-18 0:10 ` Sasha Levin
2022-10-18 0:10 ` [Cluster-devel] " Sasha Levin
` (13 subsequent siblings)
14 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Michael S . Tsirkin, virtualization, Angus Chen
From: Angus Chen <angus.chen@jaguarmicro.com>
[ Upstream commit 71491c54eafa318fdd24a1f26a1c82b28e1ac21d ]
The background is that we use dpu in cloud computing,the arch is x86,80
cores. We will have a lots of virtio devices,like 512 or more.
When we probe about 200 virtio_blk devices,it will fail and
the stack is printed as follows:
[25338.485128] virtio-pci 0000:b3:00.0: virtio_pci: leaving for legacy driver
[25338.496174] genirq: Flags mismatch irq 0. 00000080 (virtio418) vs. 00015a00 (timer)
[25338.503822] CPU: 20 PID: 5431 Comm: kworker/20:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.30.1.el8.x86_64
[25338.516403] Hardware name: Inspur NF5280M5/YZMB-00882-10E, BIOS 4.1.21 08/25/2021
[25338.523881] Workqueue: events work_for_cpu_fn
[25338.528235] Call Trace:
[25338.530687] dump_stack+0x5c/0x80
[25338.534000] __setup_irq.cold.53+0x7c/0xd3
[25338.538098] request_threaded_irq+0xf5/0x160
[25338.542371] vp_find_vqs+0xc7/0x190
[25338.545866] init_vq+0x17c/0x2e0 [virtio_blk]
[25338.550223] ? ncpus_cmp_func+0x10/0x10
[25338.554061] virtblk_probe+0xe6/0x8a0 [virtio_blk]
[25338.558846] virtio_dev_probe+0x158/0x1f0
[25338.562861] really_probe+0x255/0x4a0
[25338.566524] ? __driver_attach_async_helper+0x90/0x90
[25338.571567] driver_probe_device+0x49/0xc0
[25338.575660] bus_for_each_drv+0x79/0xc0
[25338.579499] __device_attach+0xdc/0x160
[25338.583337] bus_probe_device+0x9d/0xb0
[25338.587167] device_add+0x418/0x780
[25338.590654] register_virtio_device+0x9e/0xe0
[25338.595011] virtio_pci_probe+0xb3/0x140
[25338.598941] local_pci_probe+0x41/0x90
[25338.602689] work_for_cpu_fn+0x16/0x20
[25338.606443] process_one_work+0x1a7/0x360
[25338.610456] ? create_worker+0x1a0/0x1a0
[25338.614381] worker_thread+0x1cf/0x390
[25338.618132] ? create_worker+0x1a0/0x1a0
[25338.622051] kthread+0x116/0x130
[25338.625283] ? kthread_flush_work_fn+0x10/0x10
[25338.629731] ret_from_fork+0x1f/0x40
[25338.633395] virtio_blk: probe of virtio418 failed with error -16
The log :
"genirq: Flags mismatch irq 0. 00000080 (virtio418) vs. 00015a00 (timer)"
was printed because of the irq 0 is used by timer exclusive,and when
vp_find_vqs call vp_find_vqs_msix and returns false twice (for
whatever reason), then it will call vp_find_vqs_intx as a fallback.
Because vp_dev->pci_dev->irq is zero, we request irq 0 with
flag IRQF_SHARED, and get a backtrace like above.
According to PCI spec about "Interrupt Pin" Register (Offset 3Dh):
"The Interrupt Pin register is a read-only register that identifies the
legacy interrupt Message(s) the Function uses. Valid values are 01h, 02h,
03h, and 04h that map to legacy interrupt Messages for INTA,
INTB, INTC, and INTD respectively. A value of 00h indicates that the
Function uses no legacy interrupt Message(s)."
So if vp_dev->pci_dev->pin is zero, we should not request legacy
interrupt.
Signed-off-by: Angus Chen <angus.chen@jaguarmicro.com>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20220930000915.548-1-angus.chen@jaguarmicro.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/virtio/virtio_pci_common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
index 1e890ef17687..0b4b3011ff92 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -403,6 +403,9 @@ int vp_find_vqs(struct virtio_device *vdev, unsigned nvqs,
err = vp_find_vqs_msix(vdev, nvqs, vqs, callbacks, names, false, ctx, desc);
if (!err)
return 0;
+ /* Is there an interrupt pin? If not give up. */
+ if (!(to_vp_device(vdev)->pci_dev->pin))
+ return err;
/* Finally fall back to regular interrupts. */
return vp_find_vqs_intx(vdev, nvqs, vqs, callbacks, names, ctx);
}
--
2.35.1
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH AUTOSEL 5.10 16/16] virtio_pci: don't try to use intxif pin is zero
@ 2022-10-18 0:10 ` Sasha Levin
0 siblings, 0 replies; 26+ messages in thread
From: Sasha Levin @ 2022-10-18 0:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Angus Chen, Michael S . Tsirkin, Sasha Levin, jasowang, virtualization
From: Angus Chen <angus.chen@jaguarmicro.com>
[ Upstream commit 71491c54eafa318fdd24a1f26a1c82b28e1ac21d ]
The background is that we use dpu in cloud computing,the arch is x86,80
cores. We will have a lots of virtio devices,like 512 or more.
When we probe about 200 virtio_blk devices,it will fail and
the stack is printed as follows:
[25338.485128] virtio-pci 0000:b3:00.0: virtio_pci: leaving for legacy driver
[25338.496174] genirq: Flags mismatch irq 0. 00000080 (virtio418) vs. 00015a00 (timer)
[25338.503822] CPU: 20 PID: 5431 Comm: kworker/20:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.30.1.el8.x86_64
[25338.516403] Hardware name: Inspur NF5280M5/YZMB-00882-10E, BIOS 4.1.21 08/25/2021
[25338.523881] Workqueue: events work_for_cpu_fn
[25338.528235] Call Trace:
[25338.530687] dump_stack+0x5c/0x80
[25338.534000] __setup_irq.cold.53+0x7c/0xd3
[25338.538098] request_threaded_irq+0xf5/0x160
[25338.542371] vp_find_vqs+0xc7/0x190
[25338.545866] init_vq+0x17c/0x2e0 [virtio_blk]
[25338.550223] ? ncpus_cmp_func+0x10/0x10
[25338.554061] virtblk_probe+0xe6/0x8a0 [virtio_blk]
[25338.558846] virtio_dev_probe+0x158/0x1f0
[25338.562861] really_probe+0x255/0x4a0
[25338.566524] ? __driver_attach_async_helper+0x90/0x90
[25338.571567] driver_probe_device+0x49/0xc0
[25338.575660] bus_for_each_drv+0x79/0xc0
[25338.579499] __device_attach+0xdc/0x160
[25338.583337] bus_probe_device+0x9d/0xb0
[25338.587167] device_add+0x418/0x780
[25338.590654] register_virtio_device+0x9e/0xe0
[25338.595011] virtio_pci_probe+0xb3/0x140
[25338.598941] local_pci_probe+0x41/0x90
[25338.602689] work_for_cpu_fn+0x16/0x20
[25338.606443] process_one_work+0x1a7/0x360
[25338.610456] ? create_worker+0x1a0/0x1a0
[25338.614381] worker_thread+0x1cf/0x390
[25338.618132] ? create_worker+0x1a0/0x1a0
[25338.622051] kthread+0x116/0x130
[25338.625283] ? kthread_flush_work_fn+0x10/0x10
[25338.629731] ret_from_fork+0x1f/0x40
[25338.633395] virtio_blk: probe of virtio418 failed with error -16
The log :
"genirq: Flags mismatch irq 0. 00000080 (virtio418) vs. 00015a00 (timer)"
was printed because of the irq 0 is used by timer exclusive,and when
vp_find_vqs call vp_find_vqs_msix and returns false twice (for
whatever reason), then it will call vp_find_vqs_intx as a fallback.
Because vp_dev->pci_dev->irq is zero, we request irq 0 with
flag IRQF_SHARED, and get a backtrace like above.
According to PCI spec about "Interrupt Pin" Register (Offset 3Dh):
"The Interrupt Pin register is a read-only register that identifies the
legacy interrupt Message(s) the Function uses. Valid values are 01h, 02h,
03h, and 04h that map to legacy interrupt Messages for INTA,
INTB, INTC, and INTD respectively. A value of 00h indicates that the
Function uses no legacy interrupt Message(s)."
So if vp_dev->pci_dev->pin is zero, we should not request legacy
interrupt.
Signed-off-by: Angus Chen <angus.chen@jaguarmicro.com>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20220930000915.548-1-angus.chen@jaguarmicro.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/virtio/virtio_pci_common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
index 1e890ef17687..0b4b3011ff92 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -403,6 +403,9 @@ int vp_find_vqs(struct virtio_device *vdev, unsigned nvqs,
err = vp_find_vqs_msix(vdev, nvqs, vqs, callbacks, names, false, ctx, desc);
if (!err)
return 0;
+ /* Is there an interrupt pin? If not give up. */
+ if (!(to_vp_device(vdev)->pci_dev->pin))
+ return err;
/* Finally fall back to regular interrupts. */
return vp_find_vqs_intx(vdev, nvqs, vqs, callbacks, names, ctx);
}
--
2.35.1
^ permalink raw reply related [flat|nested] 26+ messages in thread