[patch V2 24/28] x86/speculation: Prepare arch_smt_update() for PRCTL mode
The upcoming fine grained per task STIBP control needs to be updated on CPU
hotplug as well.
Split out the code which controls the strict mode so the prctl control code
can be added later. Mark the SMP function call argument __unused while at it.
Signed-off-by: Thomas Gleixner
---
v1 -> v2: s/app2app/user/. Mark smp function argument __unused
---
arch/x86/kernel/cpu/bugs.c | 46 -
1 file changed, 25 insertions(+), 21 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -530,40 +530,44 @@ static void __init spectre_v2_select_mit
arch_smt_update();
}
-static bool stibp_needed(void)
+static void update_stibp_msr(void * __unused)
{
- /* Enhanced IBRS makes using STIBP unnecessary. */
- if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
- return false;
-
- /* Check for strict user mitigation mode */
- return spectre_v2_user == SPECTRE_V2_USER_STRICT;
+ wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
}
-static void update_stibp_msr(void *info)
+/* Update x86_spec_ctrl_base in case SMT state changed. */
+static void update_stibp_strict(void)
{
- wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+ u64 mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
+
+ if (sched_smt_active())
+ mask |= SPEC_CTRL_STIBP;
+
+ if (mask == x86_spec_ctrl_base)
+ return;
+
+ pr_info("Spectre v2 user space SMT mitigation: STIBP %s\n",
+ mask & SPEC_CTRL_STIBP ? "always-on" : "off");
+ x86_spec_ctrl_base = mask;
+ on_each_cpu(update_stibp_msr, NULL, 1);
}
void arch_smt_update(void)
{
- u64 mask;
-
- if (!stibp_needed())
+ /* Enhanced IBRS implies STIBP. No update required. */
+ if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
return;
mutex_lock(_ctrl_mutex);
- mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
- if (sched_smt_active())
- mask |= SPEC_CTRL_STIBP;
-
- if (mask != x86_spec_ctrl_base) {
- pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
- mask & SPEC_CTRL_STIBP ? "Enabling" : "Disabling");
- x86_spec_ctrl_base = mask;
- on_each_cpu(update_stibp_msr, NULL, 1);
+ switch (spectre_v2_user) {
+ case SPECTRE_V2_USER_NONE:
+ break;
+ case SPECTRE_V2_USER_STRICT:
+ update_stibp_strict();
+ break;
}
+
mutex_unlock(_ctrl_mutex);
}
[patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode
If 'prctl' mode of user space protection from spectre v2 is selected
on the kernel command-line, STIBP and IBPB are applied on tasks which
restrict their indirect branch speculation via prctl.
SECCOMP enables the SSBD mitigation for sandboxed tasks already, so it
makes sense to prevent spectre v2 user space to user space attacks as
well.
The mitigation guide documents how STIPB works:
Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
prevents the predicted targets of indirect branches on any logical
processor of that core from being controlled by software that executes
(or executed previously) on another logical processor of the same core.
Ergo setting STIBP protects the task itself from being attacked from a task
running on a different hyper-thread and protects the tasks running on
different hyper-threads from being attacked.
IBPB is issued when the task switches out, so malicious sandbox code cannot
mistrain the branch predictor for the next user space task on the same
logical processor.
Signed-off-by: Jiri Kosina
Signed-off-by: Thomas Gleixner
---
Documentation/admin-guide/kernel-parameters.txt |9 -
arch/x86/include/asm/nospec-branch.h|1 +
arch/x86/kernel/cpu/bugs.c | 17 -
3 files changed, 25 insertions(+), 2 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4241,9 +4241,16 @@
per thread. The mitigation control state
is inherited on fork.
+ seccomp
+ - Same as "prctl" above, but all seccomp
+ threads will enable the mitigation unless
+ they explicitly opt out.
+
auto- Kernel selects the mitigation depending on
the available CPU features and vulnerability.
- Default is prctl.
+
+ Default mitigation:
+ If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
Not specifying this option is equivalent to
spectre_v2_user=auto.
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -233,6 +233,7 @@ enum spectre_v2_user_mitigation {
SPECTRE_V2_USER_NONE,
SPECTRE_V2_USER_STRICT,
SPECTRE_V2_USER_PRCTL,
+ SPECTRE_V2_USER_SECCOMP,
};
/* The Speculative Store Bypass disable variants */
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -256,12 +256,14 @@ enum spectre_v2_user_cmd {
SPECTRE_V2_USER_CMD_AUTO,
SPECTRE_V2_USER_CMD_FORCE,
SPECTRE_V2_USER_CMD_PRCTL,
+ SPECTRE_V2_USER_CMD_SECCOMP,
};
static const char * const spectre_v2_user_strings[] = {
[SPECTRE_V2_USER_NONE] = "User space: Vulnerable",
[SPECTRE_V2_USER_STRICT]= "User space: Mitigation: STIBP
protection",
[SPECTRE_V2_USER_PRCTL] = "User space: Mitigation: STIBP via
prctl",
+ [SPECTRE_V2_USER_SECCOMP] = "User space: Mitigation: STIBP via
seccomp and prctl",
};
static const struct {
@@ -273,6 +275,7 @@ static const struct {
{ "off",SPECTRE_V2_USER_CMD_NONE, false },
{ "on", SPECTRE_V2_USER_CMD_FORCE, true },
{ "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
+ { "seccomp",SPECTRE_V2_USER_CMD_SECCOMP,false },
};
static void __init spec_v2_user_print_cond(const char *reason, bool secure)
@@ -332,10 +335,16 @@ spectre_v2_user_select_mitigation(enum s
case SPECTRE_V2_USER_CMD_FORCE:
mode = SPECTRE_V2_USER_STRICT;
break;
- case SPECTRE_V2_USER_CMD_AUTO:
case SPECTRE_V2_USER_CMD_PRCTL:
mode = SPECTRE_V2_USER_PRCTL;
break;
+ case SPECTRE_V2_USER_CMD_AUTO:
+ case SPECTRE_V2_USER_CMD_SECCOMP:
+ if (IS_ENABLED(CONFIG_SECCOMP))
+ mode = SPECTRE_V2_USER_SECCOMP;
+ else
+ mode = SPECTRE_V2_USER_PRCTL;
+ break;
}
/* Initialize Indirect Branch Prediction Barrier */
@@ -347,6 +356,7 @@ spectre_v2_user_select_mitigation(enum s
static_branch_enable(_mm_always_ibpb);
break;
case SPECTRE_V2_USER_PRCTL:
+ case SPECTRE_V2_USER_SECCOMP:
static_branch_enable(_mm_cond_ibpb);
break;
default:
@@ -591,6 +601,7 @@ void arch_smt_update(void)
update_stibp_strict();
break;
case SPECTRE_V2_USER_PRCTL:
+ case SPECTRE_V2_USER_SECCOMP:
update_indir_branch_cond();
[patch V2 17/28] x86/speculation: Add command line control for indirect branch speculation
Add command line control for user space indirect branch speculation
mitigations. The new option is: spectre_v2_user=
The initial options are:
- on: Unconditionally enabled
- off: Unconditionally disabled
-auto: Kernel selects mitigation (default off for now)
When the spectre_v2= command line argument is either 'on' or 'off' this
implies that the application to application control follows that state even
if a contradicting spectre_v2_user= argument is supplied.
Originally-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
V1 -> V2: Change the option to spectre_v2_user=
---
Documentation/admin-guide/kernel-parameters.txt | 32 +
arch/x86/include/asm/nospec-branch.h| 10 +
arch/x86/kernel/cpu/bugs.c | 133
3 files changed, 156 insertions(+), 19 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4194,9 +4194,13 @@
spectre_v2= [X86] Control mitigation of Spectre variant 2
(indirect branch speculation) vulnerability.
+ The default operation protects the kernel from
+ user space attacks.
- on - unconditionally enable
- off - unconditionally disable
+ on - unconditionally enable, implies
+ spectre_v2_user=on
+ off - unconditionally disable, implies
+ spectre_v2_user=off
auto - kernel detects whether your CPU model is
vulnerable
@@ -4206,6 +4210,12 @@
CONFIG_RETPOLINE configuration option, and the
compiler with which the kernel was built.
+ Selecting 'on' will also enable the mitigation
+ against user space to user space task attacks.
+
+ Selecting 'off' will disable both the kernel and
+ the user space protections.
+
Specific mitigations can also be selected manually:
retpoline - replace indirect branches
@@ -4215,6 +4225,24 @@
Not specifying this option is equivalent to
spectre_v2=auto.
+ spectre_v2_user=
+ [X86] Control mitigation of Spectre variant 2
+ (indirect branch speculation) vulnerability between
+ user space tasks
+
+ on - Unconditionally enable mitigations. Is
+ enforced by spectre_v2=on
+
+ off - Unconditionally disable mitigations. Is
+ enforced by spectre_v2=off
+
+ auto- Kernel selects the mitigation depending on
+ the available CPU features and vulnerability.
+ Default is off.
+
+ Not specifying this option is equivalent to
+ spectre_v2_user=auto.
+
spec_store_bypass_disable=
[HW] Control Speculative Store Bypass (SSB) Disable
mitigation
(Speculative Store Bypass vulnerability)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -3,6 +3,8 @@
#ifndef _ASM_X86_NOSPEC_BRANCH_H_
#define _ASM_X86_NOSPEC_BRANCH_H_
+#include
+
#include
#include
#include
@@ -226,6 +228,12 @@ enum spectre_v2_mitigation {
SPECTRE_V2_IBRS_ENHANCED,
};
+/* The indirect branch speculation control variants */
+enum spectre_v2_user_mitigation {
+ SPECTRE_V2_USER_NONE,
+ SPECTRE_V2_USER_STRICT,
+};
+
/* The Speculative Store Bypass disable variants */
enum ssb_mitigation {
SPEC_STORE_BYPASS_NONE,
@@ -303,6 +311,8 @@ do {
\
preempt_enable(); \
} while (0)
+DECLARE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+
#endif /* __ASSEMBLY__ */
/*
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -54,6 +54,9 @@ static u64 __ro_after_init x86_spec_ctrl
u64 __ro_after_init x86_amd_ls_cfg_base;
u64 __ro_after_init x86_amd_ls_cfg_ssbd_mask;
+/* Control conditional STIPB in switch_to() */
+DEFINE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+
void __init check_bugs(void)
{
identify_boot_cpu();
@@ -199,6 +202,9 @@ static void x86_amd_ssb_disable(void)
static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
SPECTRE_V2_NONE;
+static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init =
+ SPECTRE_V2_USER_NONE;
+
#ifdef RETPOLINE
static bool spectre_v2_bad_module;
@@ -237,6 +243,104 @@ enum
[patch V2 18/28] x86/speculation: Prepare for per task indirect branch speculation control
To avoid the overhead of STIBP always on, it's necessary to allow per task
control of STIBP.
Add a new task flag TIF_SPEC_IB and evaluate it during context switch if
SMT is active and flag evaluation is enabled by the speculation control
code. Add the conditional evaluation to x86_virt_spec_ctrl() as well so the
guest/host switch works properly.
This has no effect because TIF_SPEC_IB cannot be set yet and the static key
which controls evaluation is off. Preparatory patch for adding the control
code.
[ tglx: Simplify the context switch logic and make the TIF evaluation
depend on SMP=y and on the static key controlling the conditional
update. Rename it to TIF_SPEC_IB because it controls both STIBP and
IBPB ]
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
v1 -> v2: Remove pointless include. Use consistent comments.
---
arch/x86/include/asm/msr-index.h |5 +++--
arch/x86/include/asm/spec-ctrl.h | 12
arch/x86/include/asm/thread_info.h |5 -
arch/x86/kernel/cpu/bugs.c |4
arch/x86/kernel/process.c | 23 +--
5 files changed, 44 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -41,9 +41,10 @@
#define MSR_IA32_SPEC_CTRL 0x0048 /* Speculation Control */
#define SPEC_CTRL_IBRS (1 << 0) /* Indirect Branch
Restricted Speculation */
-#define SPEC_CTRL_STIBP(1 << 1) /* Single Thread
Indirect Branch Predictors */
+#define SPEC_CTRL_STIBP_SHIFT 1 /* Single Thread Indirect
Branch Predictor (STIBP) bit */
+#define SPEC_CTRL_STIBP(1 << SPEC_CTRL_STIBP_SHIFT)
/* STIBP mask */
#define SPEC_CTRL_SSBD_SHIFT 2 /* Speculative Store Bypass
Disable bit */
-#define SPEC_CTRL_SSBD (1 << SPEC_CTRL_SSBD_SHIFT) /*
Speculative Store Bypass Disable */
+#define SPEC_CTRL_SSBD (1 << SPEC_CTRL_SSBD_SHIFT) /*
Speculative Store Bypass Disable */
#define MSR_IA32_PRED_CMD 0x0049 /* Prediction Command */
#define PRED_CMD_IBPB (1 << 0) /* Indirect Branch
Prediction Barrier */
--- a/arch/x86/include/asm/spec-ctrl.h
+++ b/arch/x86/include/asm/spec-ctrl.h
@@ -53,12 +53,24 @@ static inline u64 ssbd_tif_to_spec_ctrl(
return (tifn & _TIF_SSBD) >> (TIF_SSBD - SPEC_CTRL_SSBD_SHIFT);
}
+static inline u64 stibp_tif_to_spec_ctrl(u64 tifn)
+{
+ BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
+ return (tifn & _TIF_SPEC_IB) >> (TIF_SPEC_IB - SPEC_CTRL_STIBP_SHIFT);
+}
+
static inline unsigned long ssbd_spec_ctrl_to_tif(u64 spec_ctrl)
{
BUILD_BUG_ON(TIF_SSBD < SPEC_CTRL_SSBD_SHIFT);
return (spec_ctrl & SPEC_CTRL_SSBD) << (TIF_SSBD -
SPEC_CTRL_SSBD_SHIFT);
}
+static inline unsigned long stibp_spec_ctrl_to_tif(u64 spec_ctrl)
+{
+ BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
+ return (spec_ctrl & SPEC_CTRL_STIBP) << (TIF_SPEC_IB -
SPEC_CTRL_STIBP_SHIFT);
+}
+
static inline u64 ssbd_tif_to_amd_ls_cfg(u64 tifn)
{
return (tifn & _TIF_SSBD) ? x86_amd_ls_cfg_ssbd_mask : 0ULL;
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -83,6 +83,7 @@ struct thread_info {
#define TIF_SYSCALL_EMU6 /* syscall emulation active */
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
+#define TIF_SPEC_IB9 /* Indirect branch speculation
mitigation */
#define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */
#define TIF_UPROBE 12 /* breakpointed or singlestepping */
#define TIF_PATCH_PENDING 13 /* pending live patching update */
@@ -110,6 +111,7 @@ struct thread_info {
#define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
#define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
@@ -146,7 +148,8 @@ struct thread_info {
/* flags to check in __switch_to() */
#define _TIF_WORK_CTXSW
\
- (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP|_TIF_SSBD)
+ (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP| \
+_TIF_SSBD|_TIF_SPEC_IB)
#define _TIF_WORK_CTXSW_PREV (_TIF_WORK_CTXSW|_TIF_USER_RETURN_NOTIFY)
#define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -148,6 +148,10 @@ x86_virt_spec_ctrl(u64 guest_spec_ctrl,
static_cpu_has(X86_FEATURE_AMD_SSBD))
[patch V2 28/28] x86/speculation: Provide IBPB always command line options
Provide the possibility to enable IBPB always in combination with 'prctl'
and 'seccomp'.
Add the extra command line options and rework the IBPB selection to
evaluate the command instead of the mode selected by the STIPB switch case.
Signed-off-by: Thomas Gleixner
---
Documentation/admin-guide/kernel-parameters.txt | 12
arch/x86/kernel/cpu/bugs.c | 34
2 files changed, 35 insertions(+), 11 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4241,11 +4241,23 @@
per thread. The mitigation control state
is inherited on fork.
+ prctl,ibpb
+ - Like "prctl" above, but only STIBP is
+ controlled per thread. IBPB is issued
+ always when switching between different user
+ space processes.
+
seccomp
- Same as "prctl" above, but all seccomp
threads will enable the mitigation unless
they explicitly opt out.
+ seccomp,ibpb
+ - Like "seccomp" above, but only STIBP is
+ controlled per thread. IBPB is issued
+ always when switching between different
+ user space processes.
+
auto- Kernel selects the mitigation depending on
the available CPU features and vulnerability.
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -256,7 +256,9 @@ enum spectre_v2_user_cmd {
SPECTRE_V2_USER_CMD_AUTO,
SPECTRE_V2_USER_CMD_FORCE,
SPECTRE_V2_USER_CMD_PRCTL,
+ SPECTRE_V2_USER_CMD_PRCTL_IBPB,
SPECTRE_V2_USER_CMD_SECCOMP,
+ SPECTRE_V2_USER_CMD_SECCOMP_IBPB,
};
static const char * const spectre_v2_user_strings[] = {
@@ -271,11 +273,13 @@ static const struct {
enum spectre_v2_user_cmdcmd;
boolsecure;
} v2_user_options[] __initdata = {
- { "auto", SPECTRE_V2_USER_CMD_AUTO, false },
- { "off",SPECTRE_V2_USER_CMD_NONE, false },
- { "on", SPECTRE_V2_USER_CMD_FORCE, true },
- { "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
- { "seccomp",SPECTRE_V2_USER_CMD_SECCOMP,false },
+ { "auto", SPECTRE_V2_USER_CMD_AUTO, false },
+ { "off",SPECTRE_V2_USER_CMD_NONE, false },
+ { "on", SPECTRE_V2_USER_CMD_FORCE, true },
+ { "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
+ { "prctl,ibpb", SPECTRE_V2_USER_CMD_PRCTL_IBPB, false },
+ { "seccomp",SPECTRE_V2_USER_CMD_SECCOMP,false },
+ { "seccomp,ibpb", SPECTRE_V2_USER_CMD_SECCOMP_IBPB, false },
};
static void __init spec_v2_user_print_cond(const char *reason, bool secure)
@@ -321,6 +325,7 @@ spectre_v2_user_select_mitigation(enum s
{
enum spectre_v2_user_mitigation mode = SPECTRE_V2_USER_NONE;
bool smt_possible = IS_ENABLED(CONFIG_SMP);
+ enum spectre_v2_user_cmd cmd;
if (!boot_cpu_has(X86_FEATURE_IBPB) && !boot_cpu_has(X86_FEATURE_STIBP))
return;
@@ -329,17 +334,20 @@ spectre_v2_user_select_mitigation(enum s
cpu_smt_control == CPU_SMT_NOT_SUPPORTED)
smt_possible = false;
- switch (spectre_v2_parse_user_cmdline(v2_cmd)) {
+ cmd = spectre_v2_parse_user_cmdline(v2_cmd);
+ switch (cmd) {
case SPECTRE_V2_USER_CMD_NONE:
goto set_mode;
case SPECTRE_V2_USER_CMD_FORCE:
mode = SPECTRE_V2_USER_STRICT;
break;
case SPECTRE_V2_USER_CMD_PRCTL:
+ case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
mode = SPECTRE_V2_USER_PRCTL;
break;
case SPECTRE_V2_USER_CMD_AUTO:
case SPECTRE_V2_USER_CMD_SECCOMP:
+ case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
if (IS_ENABLED(CONFIG_SECCOMP))
mode = SPECTRE_V2_USER_SECCOMP;
else
@@ -351,12 +359,15 @@ spectre_v2_user_select_mitigation(enum s
if (boot_cpu_has(X86_FEATURE_IBPB)) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
- switch (mode) {
- case SPECTRE_V2_USER_STRICT:
+ switch (cmd) {
+ case SPECTRE_V2_USER_CMD_FORCE:
+ case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
+ case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
[patch V2 13/28] x86/speculation: Reorder the spec_v2 code
Reorder the code so it is better grouped.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c | 168 ++---
1 file changed, 84 insertions(+), 84 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -124,29 +124,6 @@ void __init check_bugs(void)
#endif
}
-/* The kernel command line selection */
-enum spectre_v2_mitigation_cmd {
- SPECTRE_V2_CMD_NONE,
- SPECTRE_V2_CMD_AUTO,
- SPECTRE_V2_CMD_FORCE,
- SPECTRE_V2_CMD_RETPOLINE,
- SPECTRE_V2_CMD_RETPOLINE_GENERIC,
- SPECTRE_V2_CMD_RETPOLINE_AMD,
-};
-
-static const char *spectre_v2_strings[] = {
- [SPECTRE_V2_NONE] = "Vulnerable",
- [SPECTRE_V2_RETPOLINE_GENERIC] = "Mitigation: Full generic
retpoline",
- [SPECTRE_V2_RETPOLINE_AMD] = "Mitigation: Full AMD
retpoline",
- [SPECTRE_V2_IBRS_ENHANCED] = "Mitigation: Enhanced IBRS",
-};
-
-#undef pr_fmt
-#define pr_fmt(fmt) "Spectre V2 : " fmt
-
-static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
- SPECTRE_V2_NONE;
-
void
x86_virt_spec_ctrl(u64 guest_spec_ctrl, u64 guest_virt_spec_ctrl, bool
setguest)
{
@@ -216,6 +193,12 @@ static void x86_amd_ssb_disable(void)
wrmsrl(MSR_AMD64_LS_CFG, msrval);
}
+#undef pr_fmt
+#define pr_fmt(fmt) "Spectre V2 : " fmt
+
+static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
+ SPECTRE_V2_NONE;
+
#ifdef RETPOLINE
static bool spectre_v2_bad_module;
@@ -237,18 +220,6 @@ static inline const char *spectre_v2_mod
static inline const char *spectre_v2_module_string(void) { return ""; }
#endif
-static void __init spec2_print_if_insecure(const char *reason)
-{
- if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
- pr_info("%s selected on command line.\n", reason);
-}
-
-static void __init spec2_print_if_secure(const char *reason)
-{
- if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
- pr_info("%s selected on command line.\n", reason);
-}
-
static inline bool match_option(const char *arg, int arglen, const char *opt)
{
int len = strlen(opt);
@@ -256,24 +227,53 @@ static inline bool match_option(const ch
return len == arglen && !strncmp(arg, opt, len);
}
+/* The kernel command line selection for spectre v2 */
+enum spectre_v2_mitigation_cmd {
+ SPECTRE_V2_CMD_NONE,
+ SPECTRE_V2_CMD_AUTO,
+ SPECTRE_V2_CMD_FORCE,
+ SPECTRE_V2_CMD_RETPOLINE,
+ SPECTRE_V2_CMD_RETPOLINE_GENERIC,
+ SPECTRE_V2_CMD_RETPOLINE_AMD,
+};
+
+static const char *spectre_v2_strings[] = {
+ [SPECTRE_V2_NONE] = "Vulnerable",
+ [SPECTRE_V2_RETPOLINE_GENERIC] = "Mitigation: Full generic
retpoline",
+ [SPECTRE_V2_RETPOLINE_AMD] = "Mitigation: Full AMD
retpoline",
+ [SPECTRE_V2_IBRS_ENHANCED] = "Mitigation: Enhanced IBRS",
+};
+
static const struct {
const char *option;
enum spectre_v2_mitigation_cmd cmd;
bool secure;
} mitigation_options[] = {
- { "off", SPECTRE_V2_CMD_NONE, false },
- { "on",SPECTRE_V2_CMD_FORCE, true },
- { "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
- { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_AMD, false },
- { "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
- { "auto", SPECTRE_V2_CMD_AUTO, false },
+ { "off",SPECTRE_V2_CMD_NONE, false },
+ { "on", SPECTRE_V2_CMD_FORCE, true },
+ { "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
+ { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_AMD, false },
+ { "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
+ { "auto", SPECTRE_V2_CMD_AUTO, false },
};
+static void __init spec2_print_if_insecure(const char *reason)
+{
+ if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ pr_info("%s selected on command line.\n", reason);
+}
+
+static void __init spec2_print_if_secure(const char *reason)
+{
+ if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ pr_info("%s selected on command line.\n", reason);
+}
+
static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
{
+ enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO;
char arg[20];
int ret, i;
- enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO;
if (cmdline_find_option_bool(boot_command_line, "nospectre_v2"))
return SPECTRE_V2_CMD_NONE;
@@ -317,48 +317,6 @@ static enum spectre_v2_mitigation_cmd __
return cmd;
}
-static bool stibp_needed(void)
-{
- if (spectre_v2_enabled == SPECTRE_V2_NONE)
- return false;
[patch V2 19/28] x86/process: Consolidate and simplify switch_to_xtra() code
Move the conditional invocation of __switch_to_xtra() into an inline
function so the logic can be shared between 32 and 64 bit.
Remove the handthrough of the TSS pointer and retrieve the pointer directly
in the bitmap handling function. Use this_cpu_ptr() instead of the
per_cpu() indirection.
This is a preparatory change so integration of conditional indirect branch
speculation optimization happens only in one place.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/switch_to.h |3 ---
arch/x86/kernel/process.c| 12 +++-
arch/x86/kernel/process.h| 24
arch/x86/kernel/process_32.c | 10 +++---
arch/x86/kernel/process_64.c | 10 +++---
5 files changed, 37 insertions(+), 22 deletions(-)
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -11,9 +11,6 @@ struct task_struct *__switch_to_asm(stru
__visible struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *next);
-struct tss_struct;
-void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
- struct tss_struct *tss);
/* This runs runs on the previous thread's stack. */
static inline void prepare_switch_to(struct task_struct *next)
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -40,6 +40,8 @@
#include
#include
+#include "process.h"
+
/*
* per-CPU TSS segments. Threads are completely 'soft' on Linux,
* no more per-task TSS's. The TSS size is kept cacheline-aligned
@@ -252,11 +254,12 @@ void arch_setup_new_exec(void)
enable_cpuid();
}
-static inline void switch_to_bitmap(struct tss_struct *tss,
- struct thread_struct *prev,
+static inline void switch_to_bitmap(struct thread_struct *prev,
struct thread_struct *next,
unsigned long tifp, unsigned long tifn)
{
+ struct tss_struct *tss = this_cpu_ptr(_tss_rw);
+
if (tifn & _TIF_IO_BITMAP) {
/*
* Copy the relevant range of the IO bitmap.
@@ -461,8 +464,7 @@ void speculation_ctrl_update(unsigned lo
preempt_enable();
}
-void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
- struct tss_struct *tss)
+void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p)
{
struct thread_struct *prev, *next;
unsigned long tifp, tifn;
@@ -472,7 +474,7 @@ void __switch_to_xtra(struct task_struct
tifn = READ_ONCE(task_thread_info(next_p)->flags);
tifp = READ_ONCE(task_thread_info(prev_p)->flags);
- switch_to_bitmap(tss, prev, next, tifp, tifn);
+ switch_to_bitmap(prev, next, tifp, tifn);
propagate_user_return_notify(prev_p, next_p);
--- /dev/null
+++ b/arch/x86/kernel/process.h
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Code shared between 32 and 64 bit
+
+void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p);
+
+/*
+ * This needs to be inline to optimize for the common case where no extra
+ * work needs to be done.
+ */
+static inline void switch_to_extra(struct task_struct *prev,
+ struct task_struct *next)
+{
+ unsigned long next_tif = task_thread_info(next)->flags;
+ unsigned long prev_tif = task_thread_info(prev)->flags;
+
+ /*
+* __switch_to_xtra() handles debug registers, i/o bitmaps,
+* speculation mitigations etc.
+*/
+ if (unlikely(next_tif & _TIF_WORK_CTXSW_NEXT ||
+prev_tif & _TIF_WORK_CTXSW_PREV))
+ __switch_to_xtra(prev, next);
+}
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -59,6 +59,8 @@
#include
#include
+#include "process.h"
+
void __show_regs(struct pt_regs *regs, enum show_regs_mode mode)
{
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
@@ -232,7 +234,6 @@ EXPORT_SYMBOL_GPL(start_thread);
struct fpu *prev_fpu = >fpu;
struct fpu *next_fpu = >fpu;
int cpu = smp_processor_id();
- struct tss_struct *tss = _cpu(cpu_tss_rw, cpu);
/* never put a printk in __switch_to... printk() calls wake_up*()
indirectly */
@@ -264,12 +265,7 @@ EXPORT_SYMBOL_GPL(start_thread);
if (get_kernel_rpl() && unlikely(prev->iopl != next->iopl))
set_iopl_mask(next->iopl);
- /*
-* Now maybe handle debug registers and/or IO bitmaps
-*/
- if (unlikely(task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV ||
-task_thread_info(next_p)->flags & _TIF_WORK_CTXSW_NEXT))
- __switch_to_xtra(prev_p, next_p, tss);
+ switch_to_extra(prev_p, next_p);
/*
* Leave lazy mode, flushing any hypercalls made here.
--- a/arch/x86/kernel/process_64.c
+++
[patch V2 17/28] x86/speculation: Add command line control for indirect branch speculation
Add command line control for user space indirect branch speculation
mitigations. The new option is: spectre_v2_user=
The initial options are:
- on: Unconditionally enabled
- off: Unconditionally disabled
-auto: Kernel selects mitigation (default off for now)
When the spectre_v2= command line argument is either 'on' or 'off' this
implies that the application to application control follows that state even
if a contradicting spectre_v2_user= argument is supplied.
Originally-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
V1 -> V2: Change the option to spectre_v2_user=
---
Documentation/admin-guide/kernel-parameters.txt | 32 +
arch/x86/include/asm/nospec-branch.h| 10 +
arch/x86/kernel/cpu/bugs.c | 133
3 files changed, 156 insertions(+), 19 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4194,9 +4194,13 @@
spectre_v2= [X86] Control mitigation of Spectre variant 2
(indirect branch speculation) vulnerability.
+ The default operation protects the kernel from
+ user space attacks.
- on - unconditionally enable
- off - unconditionally disable
+ on - unconditionally enable, implies
+ spectre_v2_user=on
+ off - unconditionally disable, implies
+ spectre_v2_user=off
auto - kernel detects whether your CPU model is
vulnerable
@@ -4206,6 +4210,12 @@
CONFIG_RETPOLINE configuration option, and the
compiler with which the kernel was built.
+ Selecting 'on' will also enable the mitigation
+ against user space to user space task attacks.
+
+ Selecting 'off' will disable both the kernel and
+ the user space protections.
+
Specific mitigations can also be selected manually:
retpoline - replace indirect branches
@@ -4215,6 +4225,24 @@
Not specifying this option is equivalent to
spectre_v2=auto.
+ spectre_v2_user=
+ [X86] Control mitigation of Spectre variant 2
+ (indirect branch speculation) vulnerability between
+ user space tasks
+
+ on - Unconditionally enable mitigations. Is
+ enforced by spectre_v2=on
+
+ off - Unconditionally disable mitigations. Is
+ enforced by spectre_v2=off
+
+ auto- Kernel selects the mitigation depending on
+ the available CPU features and vulnerability.
+ Default is off.
+
+ Not specifying this option is equivalent to
+ spectre_v2_user=auto.
+
spec_store_bypass_disable=
[HW] Control Speculative Store Bypass (SSB) Disable
mitigation
(Speculative Store Bypass vulnerability)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -3,6 +3,8 @@
#ifndef _ASM_X86_NOSPEC_BRANCH_H_
#define _ASM_X86_NOSPEC_BRANCH_H_
+#include
+
#include
#include
#include
@@ -226,6 +228,12 @@ enum spectre_v2_mitigation {
SPECTRE_V2_IBRS_ENHANCED,
};
+/* The indirect branch speculation control variants */
+enum spectre_v2_user_mitigation {
+ SPECTRE_V2_USER_NONE,
+ SPECTRE_V2_USER_STRICT,
+};
+
/* The Speculative Store Bypass disable variants */
enum ssb_mitigation {
SPEC_STORE_BYPASS_NONE,
@@ -303,6 +311,8 @@ do {
\
preempt_enable(); \
} while (0)
+DECLARE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+
#endif /* __ASSEMBLY__ */
/*
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -54,6 +54,9 @@ static u64 __ro_after_init x86_spec_ctrl
u64 __ro_after_init x86_amd_ls_cfg_base;
u64 __ro_after_init x86_amd_ls_cfg_ssbd_mask;
+/* Control conditional STIPB in switch_to() */
+DEFINE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+
void __init check_bugs(void)
{
identify_boot_cpu();
@@ -199,6 +202,9 @@ static void x86_amd_ssb_disable(void)
static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
SPECTRE_V2_NONE;
+static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init =
+ SPECTRE_V2_USER_NONE;
+
#ifdef RETPOLINE
static bool spectre_v2_bad_module;
@@ -237,6 +243,104 @@ enum
[patch V2 18/28] x86/speculation: Prepare for per task indirect branch speculation control
To avoid the overhead of STIBP always on, it's necessary to allow per task
control of STIBP.
Add a new task flag TIF_SPEC_IB and evaluate it during context switch if
SMT is active and flag evaluation is enabled by the speculation control
code. Add the conditional evaluation to x86_virt_spec_ctrl() as well so the
guest/host switch works properly.
This has no effect because TIF_SPEC_IB cannot be set yet and the static key
which controls evaluation is off. Preparatory patch for adding the control
code.
[ tglx: Simplify the context switch logic and make the TIF evaluation
depend on SMP=y and on the static key controlling the conditional
update. Rename it to TIF_SPEC_IB because it controls both STIBP and
IBPB ]
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
v1 -> v2: Remove pointless include. Use consistent comments.
---
arch/x86/include/asm/msr-index.h |5 +++--
arch/x86/include/asm/spec-ctrl.h | 12
arch/x86/include/asm/thread_info.h |5 -
arch/x86/kernel/cpu/bugs.c |4
arch/x86/kernel/process.c | 23 +--
5 files changed, 44 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -41,9 +41,10 @@
#define MSR_IA32_SPEC_CTRL 0x0048 /* Speculation Control */
#define SPEC_CTRL_IBRS (1 << 0) /* Indirect Branch
Restricted Speculation */
-#define SPEC_CTRL_STIBP(1 << 1) /* Single Thread
Indirect Branch Predictors */
+#define SPEC_CTRL_STIBP_SHIFT 1 /* Single Thread Indirect
Branch Predictor (STIBP) bit */
+#define SPEC_CTRL_STIBP(1 << SPEC_CTRL_STIBP_SHIFT)
/* STIBP mask */
#define SPEC_CTRL_SSBD_SHIFT 2 /* Speculative Store Bypass
Disable bit */
-#define SPEC_CTRL_SSBD (1 << SPEC_CTRL_SSBD_SHIFT) /*
Speculative Store Bypass Disable */
+#define SPEC_CTRL_SSBD (1 << SPEC_CTRL_SSBD_SHIFT) /*
Speculative Store Bypass Disable */
#define MSR_IA32_PRED_CMD 0x0049 /* Prediction Command */
#define PRED_CMD_IBPB (1 << 0) /* Indirect Branch
Prediction Barrier */
--- a/arch/x86/include/asm/spec-ctrl.h
+++ b/arch/x86/include/asm/spec-ctrl.h
@@ -53,12 +53,24 @@ static inline u64 ssbd_tif_to_spec_ctrl(
return (tifn & _TIF_SSBD) >> (TIF_SSBD - SPEC_CTRL_SSBD_SHIFT);
}
+static inline u64 stibp_tif_to_spec_ctrl(u64 tifn)
+{
+ BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
+ return (tifn & _TIF_SPEC_IB) >> (TIF_SPEC_IB - SPEC_CTRL_STIBP_SHIFT);
+}
+
static inline unsigned long ssbd_spec_ctrl_to_tif(u64 spec_ctrl)
{
BUILD_BUG_ON(TIF_SSBD < SPEC_CTRL_SSBD_SHIFT);
return (spec_ctrl & SPEC_CTRL_SSBD) << (TIF_SSBD -
SPEC_CTRL_SSBD_SHIFT);
}
+static inline unsigned long stibp_spec_ctrl_to_tif(u64 spec_ctrl)
+{
+ BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
+ return (spec_ctrl & SPEC_CTRL_STIBP) << (TIF_SPEC_IB -
SPEC_CTRL_STIBP_SHIFT);
+}
+
static inline u64 ssbd_tif_to_amd_ls_cfg(u64 tifn)
{
return (tifn & _TIF_SSBD) ? x86_amd_ls_cfg_ssbd_mask : 0ULL;
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -83,6 +83,7 @@ struct thread_info {
#define TIF_SYSCALL_EMU6 /* syscall emulation active */
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
+#define TIF_SPEC_IB9 /* Indirect branch speculation
mitigation */
#define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */
#define TIF_UPROBE 12 /* breakpointed or singlestepping */
#define TIF_PATCH_PENDING 13 /* pending live patching update */
@@ -110,6 +111,7 @@ struct thread_info {
#define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
#define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
@@ -146,7 +148,8 @@ struct thread_info {
/* flags to check in __switch_to() */
#define _TIF_WORK_CTXSW
\
- (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP|_TIF_SSBD)
+ (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP| \
+_TIF_SSBD|_TIF_SPEC_IB)
#define _TIF_WORK_CTXSW_PREV (_TIF_WORK_CTXSW|_TIF_USER_RETURN_NOTIFY)
#define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -148,6 +148,10 @@ x86_virt_spec_ctrl(u64 guest_spec_ctrl,
static_cpu_has(X86_FEATURE_AMD_SSBD))
[patch V2 28/28] x86/speculation: Provide IBPB always command line options
Provide the possibility to enable IBPB always in combination with 'prctl'
and 'seccomp'.
Add the extra command line options and rework the IBPB selection to
evaluate the command instead of the mode selected by the STIPB switch case.
Signed-off-by: Thomas Gleixner
---
Documentation/admin-guide/kernel-parameters.txt | 12
arch/x86/kernel/cpu/bugs.c | 34
2 files changed, 35 insertions(+), 11 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4241,11 +4241,23 @@
per thread. The mitigation control state
is inherited on fork.
+ prctl,ibpb
+ - Like "prctl" above, but only STIBP is
+ controlled per thread. IBPB is issued
+ always when switching between different user
+ space processes.
+
seccomp
- Same as "prctl" above, but all seccomp
threads will enable the mitigation unless
they explicitly opt out.
+ seccomp,ibpb
+ - Like "seccomp" above, but only STIBP is
+ controlled per thread. IBPB is issued
+ always when switching between different
+ user space processes.
+
auto- Kernel selects the mitigation depending on
the available CPU features and vulnerability.
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -256,7 +256,9 @@ enum spectre_v2_user_cmd {
SPECTRE_V2_USER_CMD_AUTO,
SPECTRE_V2_USER_CMD_FORCE,
SPECTRE_V2_USER_CMD_PRCTL,
+ SPECTRE_V2_USER_CMD_PRCTL_IBPB,
SPECTRE_V2_USER_CMD_SECCOMP,
+ SPECTRE_V2_USER_CMD_SECCOMP_IBPB,
};
static const char * const spectre_v2_user_strings[] = {
@@ -271,11 +273,13 @@ static const struct {
enum spectre_v2_user_cmdcmd;
boolsecure;
} v2_user_options[] __initdata = {
- { "auto", SPECTRE_V2_USER_CMD_AUTO, false },
- { "off",SPECTRE_V2_USER_CMD_NONE, false },
- { "on", SPECTRE_V2_USER_CMD_FORCE, true },
- { "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
- { "seccomp",SPECTRE_V2_USER_CMD_SECCOMP,false },
+ { "auto", SPECTRE_V2_USER_CMD_AUTO, false },
+ { "off",SPECTRE_V2_USER_CMD_NONE, false },
+ { "on", SPECTRE_V2_USER_CMD_FORCE, true },
+ { "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
+ { "prctl,ibpb", SPECTRE_V2_USER_CMD_PRCTL_IBPB, false },
+ { "seccomp",SPECTRE_V2_USER_CMD_SECCOMP,false },
+ { "seccomp,ibpb", SPECTRE_V2_USER_CMD_SECCOMP_IBPB, false },
};
static void __init spec_v2_user_print_cond(const char *reason, bool secure)
@@ -321,6 +325,7 @@ spectre_v2_user_select_mitigation(enum s
{
enum spectre_v2_user_mitigation mode = SPECTRE_V2_USER_NONE;
bool smt_possible = IS_ENABLED(CONFIG_SMP);
+ enum spectre_v2_user_cmd cmd;
if (!boot_cpu_has(X86_FEATURE_IBPB) && !boot_cpu_has(X86_FEATURE_STIBP))
return;
@@ -329,17 +334,20 @@ spectre_v2_user_select_mitigation(enum s
cpu_smt_control == CPU_SMT_NOT_SUPPORTED)
smt_possible = false;
- switch (spectre_v2_parse_user_cmdline(v2_cmd)) {
+ cmd = spectre_v2_parse_user_cmdline(v2_cmd);
+ switch (cmd) {
case SPECTRE_V2_USER_CMD_NONE:
goto set_mode;
case SPECTRE_V2_USER_CMD_FORCE:
mode = SPECTRE_V2_USER_STRICT;
break;
case SPECTRE_V2_USER_CMD_PRCTL:
+ case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
mode = SPECTRE_V2_USER_PRCTL;
break;
case SPECTRE_V2_USER_CMD_AUTO:
case SPECTRE_V2_USER_CMD_SECCOMP:
+ case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
if (IS_ENABLED(CONFIG_SECCOMP))
mode = SPECTRE_V2_USER_SECCOMP;
else
@@ -351,12 +359,15 @@ spectre_v2_user_select_mitigation(enum s
if (boot_cpu_has(X86_FEATURE_IBPB)) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
- switch (mode) {
- case SPECTRE_V2_USER_STRICT:
+ switch (cmd) {
+ case SPECTRE_V2_USER_CMD_FORCE:
+ case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
+ case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
[patch V2 13/28] x86/speculation: Reorder the spec_v2 code
Reorder the code so it is better grouped.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c | 168 ++---
1 file changed, 84 insertions(+), 84 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -124,29 +124,6 @@ void __init check_bugs(void)
#endif
}
-/* The kernel command line selection */
-enum spectre_v2_mitigation_cmd {
- SPECTRE_V2_CMD_NONE,
- SPECTRE_V2_CMD_AUTO,
- SPECTRE_V2_CMD_FORCE,
- SPECTRE_V2_CMD_RETPOLINE,
- SPECTRE_V2_CMD_RETPOLINE_GENERIC,
- SPECTRE_V2_CMD_RETPOLINE_AMD,
-};
-
-static const char *spectre_v2_strings[] = {
- [SPECTRE_V2_NONE] = "Vulnerable",
- [SPECTRE_V2_RETPOLINE_GENERIC] = "Mitigation: Full generic
retpoline",
- [SPECTRE_V2_RETPOLINE_AMD] = "Mitigation: Full AMD
retpoline",
- [SPECTRE_V2_IBRS_ENHANCED] = "Mitigation: Enhanced IBRS",
-};
-
-#undef pr_fmt
-#define pr_fmt(fmt) "Spectre V2 : " fmt
-
-static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
- SPECTRE_V2_NONE;
-
void
x86_virt_spec_ctrl(u64 guest_spec_ctrl, u64 guest_virt_spec_ctrl, bool
setguest)
{
@@ -216,6 +193,12 @@ static void x86_amd_ssb_disable(void)
wrmsrl(MSR_AMD64_LS_CFG, msrval);
}
+#undef pr_fmt
+#define pr_fmt(fmt) "Spectre V2 : " fmt
+
+static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
+ SPECTRE_V2_NONE;
+
#ifdef RETPOLINE
static bool spectre_v2_bad_module;
@@ -237,18 +220,6 @@ static inline const char *spectre_v2_mod
static inline const char *spectre_v2_module_string(void) { return ""; }
#endif
-static void __init spec2_print_if_insecure(const char *reason)
-{
- if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
- pr_info("%s selected on command line.\n", reason);
-}
-
-static void __init spec2_print_if_secure(const char *reason)
-{
- if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
- pr_info("%s selected on command line.\n", reason);
-}
-
static inline bool match_option(const char *arg, int arglen, const char *opt)
{
int len = strlen(opt);
@@ -256,24 +227,53 @@ static inline bool match_option(const ch
return len == arglen && !strncmp(arg, opt, len);
}
+/* The kernel command line selection for spectre v2 */
+enum spectre_v2_mitigation_cmd {
+ SPECTRE_V2_CMD_NONE,
+ SPECTRE_V2_CMD_AUTO,
+ SPECTRE_V2_CMD_FORCE,
+ SPECTRE_V2_CMD_RETPOLINE,
+ SPECTRE_V2_CMD_RETPOLINE_GENERIC,
+ SPECTRE_V2_CMD_RETPOLINE_AMD,
+};
+
+static const char *spectre_v2_strings[] = {
+ [SPECTRE_V2_NONE] = "Vulnerable",
+ [SPECTRE_V2_RETPOLINE_GENERIC] = "Mitigation: Full generic
retpoline",
+ [SPECTRE_V2_RETPOLINE_AMD] = "Mitigation: Full AMD
retpoline",
+ [SPECTRE_V2_IBRS_ENHANCED] = "Mitigation: Enhanced IBRS",
+};
+
static const struct {
const char *option;
enum spectre_v2_mitigation_cmd cmd;
bool secure;
} mitigation_options[] = {
- { "off", SPECTRE_V2_CMD_NONE, false },
- { "on",SPECTRE_V2_CMD_FORCE, true },
- { "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
- { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_AMD, false },
- { "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
- { "auto", SPECTRE_V2_CMD_AUTO, false },
+ { "off",SPECTRE_V2_CMD_NONE, false },
+ { "on", SPECTRE_V2_CMD_FORCE, true },
+ { "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
+ { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_AMD, false },
+ { "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
+ { "auto", SPECTRE_V2_CMD_AUTO, false },
};
+static void __init spec2_print_if_insecure(const char *reason)
+{
+ if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ pr_info("%s selected on command line.\n", reason);
+}
+
+static void __init spec2_print_if_secure(const char *reason)
+{
+ if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ pr_info("%s selected on command line.\n", reason);
+}
+
static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
{
+ enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO;
char arg[20];
int ret, i;
- enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO;
if (cmdline_find_option_bool(boot_command_line, "nospectre_v2"))
return SPECTRE_V2_CMD_NONE;
@@ -317,48 +317,6 @@ static enum spectre_v2_mitigation_cmd __
return cmd;
}
-static bool stibp_needed(void)
-{
- if (spectre_v2_enabled == SPECTRE_V2_NONE)
- return false;
[patch V2 19/28] x86/process: Consolidate and simplify switch_to_xtra() code
Move the conditional invocation of __switch_to_xtra() into an inline
function so the logic can be shared between 32 and 64 bit.
Remove the handthrough of the TSS pointer and retrieve the pointer directly
in the bitmap handling function. Use this_cpu_ptr() instead of the
per_cpu() indirection.
This is a preparatory change so integration of conditional indirect branch
speculation optimization happens only in one place.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/switch_to.h |3 ---
arch/x86/kernel/process.c| 12 +++-
arch/x86/kernel/process.h| 24
arch/x86/kernel/process_32.c | 10 +++---
arch/x86/kernel/process_64.c | 10 +++---
5 files changed, 37 insertions(+), 22 deletions(-)
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -11,9 +11,6 @@ struct task_struct *__switch_to_asm(stru
__visible struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *next);
-struct tss_struct;
-void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
- struct tss_struct *tss);
/* This runs runs on the previous thread's stack. */
static inline void prepare_switch_to(struct task_struct *next)
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -40,6 +40,8 @@
#include
#include
+#include "process.h"
+
/*
* per-CPU TSS segments. Threads are completely 'soft' on Linux,
* no more per-task TSS's. The TSS size is kept cacheline-aligned
@@ -252,11 +254,12 @@ void arch_setup_new_exec(void)
enable_cpuid();
}
-static inline void switch_to_bitmap(struct tss_struct *tss,
- struct thread_struct *prev,
+static inline void switch_to_bitmap(struct thread_struct *prev,
struct thread_struct *next,
unsigned long tifp, unsigned long tifn)
{
+ struct tss_struct *tss = this_cpu_ptr(_tss_rw);
+
if (tifn & _TIF_IO_BITMAP) {
/*
* Copy the relevant range of the IO bitmap.
@@ -461,8 +464,7 @@ void speculation_ctrl_update(unsigned lo
preempt_enable();
}
-void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
- struct tss_struct *tss)
+void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p)
{
struct thread_struct *prev, *next;
unsigned long tifp, tifn;
@@ -472,7 +474,7 @@ void __switch_to_xtra(struct task_struct
tifn = READ_ONCE(task_thread_info(next_p)->flags);
tifp = READ_ONCE(task_thread_info(prev_p)->flags);
- switch_to_bitmap(tss, prev, next, tifp, tifn);
+ switch_to_bitmap(prev, next, tifp, tifn);
propagate_user_return_notify(prev_p, next_p);
--- /dev/null
+++ b/arch/x86/kernel/process.h
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Code shared between 32 and 64 bit
+
+void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p);
+
+/*
+ * This needs to be inline to optimize for the common case where no extra
+ * work needs to be done.
+ */
+static inline void switch_to_extra(struct task_struct *prev,
+ struct task_struct *next)
+{
+ unsigned long next_tif = task_thread_info(next)->flags;
+ unsigned long prev_tif = task_thread_info(prev)->flags;
+
+ /*
+* __switch_to_xtra() handles debug registers, i/o bitmaps,
+* speculation mitigations etc.
+*/
+ if (unlikely(next_tif & _TIF_WORK_CTXSW_NEXT ||
+prev_tif & _TIF_WORK_CTXSW_PREV))
+ __switch_to_xtra(prev, next);
+}
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -59,6 +59,8 @@
#include
#include
+#include "process.h"
+
void __show_regs(struct pt_regs *regs, enum show_regs_mode mode)
{
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
@@ -232,7 +234,6 @@ EXPORT_SYMBOL_GPL(start_thread);
struct fpu *prev_fpu = >fpu;
struct fpu *next_fpu = >fpu;
int cpu = smp_processor_id();
- struct tss_struct *tss = _cpu(cpu_tss_rw, cpu);
/* never put a printk in __switch_to... printk() calls wake_up*()
indirectly */
@@ -264,12 +265,7 @@ EXPORT_SYMBOL_GPL(start_thread);
if (get_kernel_rpl() && unlikely(prev->iopl != next->iopl))
set_iopl_mask(next->iopl);
- /*
-* Now maybe handle debug registers and/or IO bitmaps
-*/
- if (unlikely(task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV ||
-task_thread_info(next_p)->flags & _TIF_WORK_CTXSW_NEXT))
- __switch_to_xtra(prev_p, next_p, tss);
+ switch_to_extra(prev_p, next_p);
/*
* Leave lazy mode, flushing any hypercalls made here.
--- a/arch/x86/kernel/process_64.c
+++
[patch V2 22/28] ptrace: Remove unused ptrace_may_access_sched() and MODE_IBRS
The IBPB control code in x86 removed the usage. Remove the functionality
which was introduced for this.
Signed-off-by: Thomas Gleixner
---
include/linux/ptrace.h | 17 -
kernel/ptrace.c| 10 --
2 files changed, 27 deletions(-)
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -64,15 +64,12 @@ extern void exit_ptrace(struct task_stru
#define PTRACE_MODE_NOAUDIT0x04
#define PTRACE_MODE_FSCREDS0x08
#define PTRACE_MODE_REALCREDS 0x10
-#define PTRACE_MODE_SCHED 0x20
-#define PTRACE_MODE_IBPB 0x40
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)
-#define PTRACE_MODE_SPEC_IBPB (PTRACE_MODE_ATTACH_REALCREDS | PTRACE_MODE_IBPB)
/**
* ptrace_may_access - check whether the caller is permitted to access
@@ -90,20 +87,6 @@ extern void exit_ptrace(struct task_stru
*/
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
-/**
- * ptrace_may_access - check whether the caller is permitted to access
- * a target task.
- * @task: target task
- * @mode: selects type of access and caller credentials
- *
- * Returns true on success, false on denial.
- *
- * Similar to ptrace_may_access(). Only to be called from context switch
- * code. Does not call into audit and the regular LSM hooks due to locking
- * constraints.
- */
-extern bool ptrace_may_access_sched(struct task_struct *task, unsigned int
mode);
-
static inline int ptrace_reparented(struct task_struct *child)
{
return !same_thread_group(child->real_parent, child->parent);
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -261,9 +261,6 @@ static int ptrace_check_attach(struct ta
static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
{
- if (mode & PTRACE_MODE_SCHED)
- return false;
-
if (mode & PTRACE_MODE_NOAUDIT)
return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
else
@@ -331,16 +328,9 @@ static int __ptrace_may_access(struct ta
!ptrace_has_cap(mm->user_ns, mode)))
return -EPERM;
- if (mode & PTRACE_MODE_SCHED)
- return 0;
return security_ptrace_access_check(task, mode);
}
-bool ptrace_may_access_sched(struct task_struct *task, unsigned int mode)
-{
- return __ptrace_may_access(task, mode | PTRACE_MODE_SCHED);
-}
-
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
[patch V2 21/28] x86/speculation: Prepare for conditional IBPB in switch_mm()
The IBPB speculation barrier is issued from switch_mm() when the kernel
switches to a user space task with a different mm than the user space task
which ran last on the same CPU.
An additional optimization is to avoid IBPB when the incoming task can be
ptraced by the outgoing task. This optimization only works when switching
directly between two user space tasks. When switching from a kernel task to
a user space task the optimization fails because the previous task cannot
be accessed anymore. So for quite some scenarios the optimization is just
adding overhead.
The upcoming conditional IBPB support will issue IBPB only for user space
tasks which have the TIF_SPEC_IB bit set. This requires to handle the
following cases:
1) Switch from a user space task (potential attacker) which has
TIF_SPEC_IB set to a user space task (potential victim) which has
TIF_SPEC_IB not set.
2) Switch from a user space task (potential attacker) which has
TIF_SPEC_IB not set to a user space task (potential victim) which has
TIF_SPEC_IB set.
This needs to be optimized for the case where the IBPB can be avoided when
only kernel threads ran in between user space tasks which belong to the
same process.
The current check whether two tasks belong to the same context is using the
tasks context id. While correct, it's simpler to use the mm pointer because
it allows to mangle the TIF_SPEC_IB bit into it. The context id based
mechanism requires extra storage, which creates worse code.
When a task is scheduled out its TIF_SPEC_IB bit is mangled as bit 0 into
the per CPU storage which is used to track the last user space mm which was
running on a CPU. This bit can be used together with the TIF_SPEC_IB bit of
the incoming task to make the decision whether IBPB needs to be issued or
not to cover the two cases above.
As conditional IBPB is going to be the default, remove the dubious ptrace
check for the IBPB always case and simply issue IBPB always when the
process changes.
Move the storage to a different place in the struct as the original one
created a hole.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/nospec-branch.h |2
arch/x86/include/asm/tlbflush.h |8 +-
arch/x86/kernel/cpu/bugs.c | 29 +++--
arch/x86/mm/tlb.c| 109 +--
4 files changed, 110 insertions(+), 38 deletions(-)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -312,6 +312,8 @@ do {
\
} while (0)
DECLARE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+DECLARE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
+DECLARE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
#endif /* __ASSEMBLY__ */
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -169,10 +169,14 @@ struct tlb_state {
#define LOADED_MM_SWITCHING ((struct mm_struct *)1)
+ /* Last user mm for optimizing IBPB */
+ union {
+ struct mm_struct*last_user_mm;
+ unsigned long last_user_mm_ibpb;
+ };
+
u16 loaded_mm_asid;
u16 next_asid;
- /* last user mm's ctx id */
- u64 last_ctx_id;
/*
* We can be in one of several states:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -56,6 +56,10 @@ u64 __ro_after_init x86_amd_ls_cfg_ssbd_
/* Control conditional STIPB in switch_to() */
DEFINE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+/* Control conditional IBPB in switch_mm() */
+DEFINE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
+/* Control unconditional IBPB in switch_mm() */
+DEFINE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
void __init check_bugs(void)
{
@@ -331,7 +335,17 @@ spectre_v2_user_select_mitigation(enum s
/* Initialize Indirect Branch Prediction Barrier */
if (boot_cpu_has(X86_FEATURE_IBPB)) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
- pr_info("Spectre v2 mitigation: Enabling Indirect Branch
Prediction Barrier\n");
+
+ switch (mode) {
+ case SPECTRE_V2_USER_STRICT:
+ static_branch_enable(_mm_always_ibpb);
+ break;
+ default:
+ break;
+ }
+
+ pr_info("mitigation: Enabling %s Indirect Branch Prediction
Barrier\n",
+ mode == SPECTRE_V2_USER_STRICT ? "always-on" :
"conditional");
}
/* If enhanced IBRS is enabled no STIPB required */
@@ -955,10 +969,15 @@ static char *stibp_state(void)
static char *ibpb_state(void)
{
- if (boot_cpu_has(X86_FEATURE_USE_IBPB))
- return ", IBPB";
- else
- return "";
+ if (boot_cpu_has(X86_FEATURE_IBPB)) {
+ switch (spectre_v2_user) {
+ case SPECTRE_V2_USER_NONE:
+ return ", IBPB: disabled";
+
[patch V2 22/28] ptrace: Remove unused ptrace_may_access_sched() and MODE_IBRS
The IBPB control code in x86 removed the usage. Remove the functionality
which was introduced for this.
Signed-off-by: Thomas Gleixner
---
include/linux/ptrace.h | 17 -
kernel/ptrace.c| 10 --
2 files changed, 27 deletions(-)
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -64,15 +64,12 @@ extern void exit_ptrace(struct task_stru
#define PTRACE_MODE_NOAUDIT0x04
#define PTRACE_MODE_FSCREDS0x08
#define PTRACE_MODE_REALCREDS 0x10
-#define PTRACE_MODE_SCHED 0x20
-#define PTRACE_MODE_IBPB 0x40
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)
-#define PTRACE_MODE_SPEC_IBPB (PTRACE_MODE_ATTACH_REALCREDS | PTRACE_MODE_IBPB)
/**
* ptrace_may_access - check whether the caller is permitted to access
@@ -90,20 +87,6 @@ extern void exit_ptrace(struct task_stru
*/
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
-/**
- * ptrace_may_access - check whether the caller is permitted to access
- * a target task.
- * @task: target task
- * @mode: selects type of access and caller credentials
- *
- * Returns true on success, false on denial.
- *
- * Similar to ptrace_may_access(). Only to be called from context switch
- * code. Does not call into audit and the regular LSM hooks due to locking
- * constraints.
- */
-extern bool ptrace_may_access_sched(struct task_struct *task, unsigned int
mode);
-
static inline int ptrace_reparented(struct task_struct *child)
{
return !same_thread_group(child->real_parent, child->parent);
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -261,9 +261,6 @@ static int ptrace_check_attach(struct ta
static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
{
- if (mode & PTRACE_MODE_SCHED)
- return false;
-
if (mode & PTRACE_MODE_NOAUDIT)
return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
else
@@ -331,16 +328,9 @@ static int __ptrace_may_access(struct ta
!ptrace_has_cap(mm->user_ns, mode)))
return -EPERM;
- if (mode & PTRACE_MODE_SCHED)
- return 0;
return security_ptrace_access_check(task, mode);
}
-bool ptrace_may_access_sched(struct task_struct *task, unsigned int mode)
-{
- return __ptrace_may_access(task, mode | PTRACE_MODE_SCHED);
-}
-
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
[patch V2 21/28] x86/speculation: Prepare for conditional IBPB in switch_mm()
The IBPB speculation barrier is issued from switch_mm() when the kernel
switches to a user space task with a different mm than the user space task
which ran last on the same CPU.
An additional optimization is to avoid IBPB when the incoming task can be
ptraced by the outgoing task. This optimization only works when switching
directly between two user space tasks. When switching from a kernel task to
a user space task the optimization fails because the previous task cannot
be accessed anymore. So for quite some scenarios the optimization is just
adding overhead.
The upcoming conditional IBPB support will issue IBPB only for user space
tasks which have the TIF_SPEC_IB bit set. This requires to handle the
following cases:
1) Switch from a user space task (potential attacker) which has
TIF_SPEC_IB set to a user space task (potential victim) which has
TIF_SPEC_IB not set.
2) Switch from a user space task (potential attacker) which has
TIF_SPEC_IB not set to a user space task (potential victim) which has
TIF_SPEC_IB set.
This needs to be optimized for the case where the IBPB can be avoided when
only kernel threads ran in between user space tasks which belong to the
same process.
The current check whether two tasks belong to the same context is using the
tasks context id. While correct, it's simpler to use the mm pointer because
it allows to mangle the TIF_SPEC_IB bit into it. The context id based
mechanism requires extra storage, which creates worse code.
When a task is scheduled out its TIF_SPEC_IB bit is mangled as bit 0 into
the per CPU storage which is used to track the last user space mm which was
running on a CPU. This bit can be used together with the TIF_SPEC_IB bit of
the incoming task to make the decision whether IBPB needs to be issued or
not to cover the two cases above.
As conditional IBPB is going to be the default, remove the dubious ptrace
check for the IBPB always case and simply issue IBPB always when the
process changes.
Move the storage to a different place in the struct as the original one
created a hole.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/nospec-branch.h |2
arch/x86/include/asm/tlbflush.h |8 +-
arch/x86/kernel/cpu/bugs.c | 29 +++--
arch/x86/mm/tlb.c| 109 +--
4 files changed, 110 insertions(+), 38 deletions(-)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -312,6 +312,8 @@ do {
\
} while (0)
DECLARE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+DECLARE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
+DECLARE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
#endif /* __ASSEMBLY__ */
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -169,10 +169,14 @@ struct tlb_state {
#define LOADED_MM_SWITCHING ((struct mm_struct *)1)
+ /* Last user mm for optimizing IBPB */
+ union {
+ struct mm_struct*last_user_mm;
+ unsigned long last_user_mm_ibpb;
+ };
+
u16 loaded_mm_asid;
u16 next_asid;
- /* last user mm's ctx id */
- u64 last_ctx_id;
/*
* We can be in one of several states:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -56,6 +56,10 @@ u64 __ro_after_init x86_amd_ls_cfg_ssbd_
/* Control conditional STIPB in switch_to() */
DEFINE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+/* Control conditional IBPB in switch_mm() */
+DEFINE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
+/* Control unconditional IBPB in switch_mm() */
+DEFINE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
void __init check_bugs(void)
{
@@ -331,7 +335,17 @@ spectre_v2_user_select_mitigation(enum s
/* Initialize Indirect Branch Prediction Barrier */
if (boot_cpu_has(X86_FEATURE_IBPB)) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
- pr_info("Spectre v2 mitigation: Enabling Indirect Branch
Prediction Barrier\n");
+
+ switch (mode) {
+ case SPECTRE_V2_USER_STRICT:
+ static_branch_enable(_mm_always_ibpb);
+ break;
+ default:
+ break;
+ }
+
+ pr_info("mitigation: Enabling %s Indirect Branch Prediction
Barrier\n",
+ mode == SPECTRE_V2_USER_STRICT ? "always-on" :
"conditional");
}
/* If enhanced IBRS is enabled no STIPB required */
@@ -955,10 +969,15 @@ static char *stibp_state(void)
static char *ibpb_state(void)
{
- if (boot_cpu_has(X86_FEATURE_USE_IBPB))
- return ", IBPB";
- else
- return "";
+ if (boot_cpu_has(X86_FEATURE_IBPB)) {
+ switch (spectre_v2_user) {
+ case SPECTRE_V2_USER_NONE:
+ return ", IBPB: disabled";
+
[patch V2 05/28] x86/speculation: Disable STIBP when enhanced IBRS is in use
If enhanced IBRS is active, STIBP is redundant for mitigating Spectre v2
user space exploits from hyperthread sibling.
Disable STIBP when enhanced IBRS is used.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c |7 +++
1 file changed, 7 insertions(+)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -321,6 +321,10 @@ static bool stibp_needed(void)
if (spectre_v2_enabled == SPECTRE_V2_NONE)
return false;
+ /* Enhanced IBRS makes using STIBP unnecessary. */
+ if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
+ return false;
+
if (!boot_cpu_has(X86_FEATURE_STIBP))
return false;
@@ -846,6 +850,9 @@ static ssize_t l1tf_show_state(char *buf
static char *stibp_state(void)
{
+ if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
+ return "";
+
if (x86_spec_ctrl_base & SPEC_CTRL_STIBP)
return ", STIBP";
else
[patch V2 04/28] x86/speculation: Reorganize cpu_show_common()
The Spectre V2 printout in cpu_show_common() handles conditionals for the
various mitigation methods directly in the sprintf() argument list. That's
hard to read and will become unreadable if more complex decisions need to
be made for a particular method.
Move the conditionals for STIBP and IBPB string selection into helper
functions, so they can be extended later on.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -844,6 +844,22 @@ static ssize_t l1tf_show_state(char *buf
}
#endif
+static char *stibp_state(void)
+{
+ if (x86_spec_ctrl_base & SPEC_CTRL_STIBP)
+ return ", STIBP";
+ else
+ return "";
+}
+
+static char *ibpb_state(void)
+{
+ if (boot_cpu_has(X86_FEATURE_USE_IBPB))
+ return ", IBPB";
+ else
+ return "";
+}
+
static ssize_t cpu_show_common(struct device *dev, struct device_attribute
*attr,
char *buf, unsigned int bug)
{
@@ -865,9 +881,9 @@ static ssize_t cpu_show_common(struct de
case X86_BUG_SPECTRE_V2:
return sprintf(buf, "%s%s%s%s%s%s\n",
spectre_v2_strings[spectre_v2_enabled],
- boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" :
"",
+ ibpb_state(),
boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ",
IBRS_FW" : "",
- (x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ",
STIBP" : "",
+ stibp_state(),
boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB
filling" : "",
spectre_v2_module_string());
[patch V2 05/28] x86/speculation: Disable STIBP when enhanced IBRS is in use
If enhanced IBRS is active, STIBP is redundant for mitigating Spectre v2
user space exploits from hyperthread sibling.
Disable STIBP when enhanced IBRS is used.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c |7 +++
1 file changed, 7 insertions(+)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -321,6 +321,10 @@ static bool stibp_needed(void)
if (spectre_v2_enabled == SPECTRE_V2_NONE)
return false;
+ /* Enhanced IBRS makes using STIBP unnecessary. */
+ if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
+ return false;
+
if (!boot_cpu_has(X86_FEATURE_STIBP))
return false;
@@ -846,6 +850,9 @@ static ssize_t l1tf_show_state(char *buf
static char *stibp_state(void)
{
+ if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
+ return "";
+
if (x86_spec_ctrl_base & SPEC_CTRL_STIBP)
return ", STIBP";
else
[patch V2 04/28] x86/speculation: Reorganize cpu_show_common()
The Spectre V2 printout in cpu_show_common() handles conditionals for the
various mitigation methods directly in the sprintf() argument list. That's
hard to read and will become unreadable if more complex decisions need to
be made for a particular method.
Move the conditionals for STIBP and IBPB string selection into helper
functions, so they can be extended later on.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -844,6 +844,22 @@ static ssize_t l1tf_show_state(char *buf
}
#endif
+static char *stibp_state(void)
+{
+ if (x86_spec_ctrl_base & SPEC_CTRL_STIBP)
+ return ", STIBP";
+ else
+ return "";
+}
+
+static char *ibpb_state(void)
+{
+ if (boot_cpu_has(X86_FEATURE_USE_IBPB))
+ return ", IBPB";
+ else
+ return "";
+}
+
static ssize_t cpu_show_common(struct device *dev, struct device_attribute
*attr,
char *buf, unsigned int bug)
{
@@ -865,9 +881,9 @@ static ssize_t cpu_show_common(struct de
case X86_BUG_SPECTRE_V2:
return sprintf(buf, "%s%s%s%s%s%s\n",
spectre_v2_strings[spectre_v2_enabled],
- boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" :
"",
+ ibpb_state(),
boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ",
IBRS_FW" : "",
- (x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ",
STIBP" : "",
+ stibp_state(),
boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB
filling" : "",
spectre_v2_module_string());
[patch V2 09/28] x86/Kconfig: Select SCHED_SMT if SMP enabled
CONFIG_SCHED_SMT is enabled by all distros, so there is not a real point to have it configurable. The runtime overhead in the core scheduler code is minimal because the actual SMT scheduling parts are conditional on a static key. This allows to expose the scheduler's SMT state static key to the speculation control code. Alternatively the scheduler's static key could be made always available when CONFIG_SMP is enabled, but that's just adding an unused static key to every other architecture for nothing. Signed-off-by: Thomas Gleixner --- arch/x86/Kconfig |8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1001,13 +1001,7 @@ config NR_CPUS to the kernel image. config SCHED_SMT - bool "SMT (Hyperthreading) scheduler support" - depends on SMP - ---help--- - SMT scheduler support improves the CPU scheduler's decision making - when dealing with Intel Pentium 4 chips with HyperThreading at a - cost of slightly increased overhead in some places. If unsure say - N here. + def_bool y if SMP config SCHED_MC def_bool y
[patch V2 11/28] x86/speculation: Rework SMT state change
arch_smt_update() is only called when the sysfs SMT control knob is
changed. This means that when SMT is enabled in the sysfs control knob the
system is considered to have SMT active even if all siblings are offline.
To allow finegrained control of the speculation mitigations, the actual SMT
state is more interesting than the fact that siblings could be enabled.
Rework the code, so arch_smt_update() is invoked from each individual CPU
hotplug function, and simplify the update function while at it.
Signed-off-by: Thomas Gleixner
---
v1 -> v2: Adapt to new header sched/smt.h
---
arch/x86/kernel/cpu/bugs.c | 11 +--
include/linux/sched/smt.h |2 ++
kernel/cpu.c | 15 +--
3 files changed, 16 insertions(+), 12 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -344,16 +345,14 @@ void arch_smt_update(void)
return;
mutex_lock(_ctrl_mutex);
- mask = x86_spec_ctrl_base;
- if (cpu_smt_control == CPU_SMT_ENABLED)
+
+ mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
+ if (sched_smt_active())
mask |= SPEC_CTRL_STIBP;
- else
- mask &= ~SPEC_CTRL_STIBP;
if (mask != x86_spec_ctrl_base) {
pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
- cpu_smt_control == CPU_SMT_ENABLED ?
- "Enabling" : "Disabling");
+ mask & SPEC_CTRL_STIBP ? "Enabling" : "Disabling");
x86_spec_ctrl_base = mask;
on_each_cpu(update_stibp_msr, NULL, 1);
}
--- a/include/linux/sched/smt.h
+++ b/include/linux/sched/smt.h
@@ -15,4 +15,6 @@ static __always_inline bool sched_smt_ac
static inline bool sched_smt_active(void) { return false; }
#endif
+void arch_smt_update(void);
+
#endif
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -367,6 +368,12 @@ static void lockdep_release_cpus_lock(vo
#endif /* CONFIG_HOTPLUG_CPU */
+/*
+ * Architectures that need SMT-specific errata handling during SMT hotplug
+ * should override this.
+ */
+void __weak arch_smt_update(void) { }
+
#ifdef CONFIG_HOTPLUG_SMT
enum cpuhp_smt_control cpu_smt_control __read_mostly = CPU_SMT_ENABLED;
EXPORT_SYMBOL_GPL(cpu_smt_control);
@@ -1011,6 +1018,7 @@ static int __ref _cpu_down(unsigned int
* concurrent CPU hotplug via cpu_add_remove_lock.
*/
lockup_detector_cleanup();
+ arch_smt_update();
return ret;
}
@@ -1139,6 +1147,7 @@ static int _cpu_up(unsigned int cpu, int
ret = cpuhp_up_callbacks(cpu, st, target);
out:
cpus_write_unlock();
+ arch_smt_update();
return ret;
}
@@ -2055,12 +2064,6 @@ static void cpuhp_online_cpu_device(unsi
kobject_uevent(>kobj, KOBJ_ONLINE);
}
-/*
- * Architectures that need SMT-specific errata handling during SMT hotplug
- * should override this.
- */
-void __weak arch_smt_update(void) { };
-
static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
[patch V2 09/28] x86/Kconfig: Select SCHED_SMT if SMP enabled
CONFIG_SCHED_SMT is enabled by all distros, so there is not a real point to have it configurable. The runtime overhead in the core scheduler code is minimal because the actual SMT scheduling parts are conditional on a static key. This allows to expose the scheduler's SMT state static key to the speculation control code. Alternatively the scheduler's static key could be made always available when CONFIG_SMP is enabled, but that's just adding an unused static key to every other architecture for nothing. Signed-off-by: Thomas Gleixner --- arch/x86/Kconfig |8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1001,13 +1001,7 @@ config NR_CPUS to the kernel image. config SCHED_SMT - bool "SMT (Hyperthreading) scheduler support" - depends on SMP - ---help--- - SMT scheduler support improves the CPU scheduler's decision making - when dealing with Intel Pentium 4 chips with HyperThreading at a - cost of slightly increased overhead in some places. If unsure say - N here. + def_bool y if SMP config SCHED_MC def_bool y
[patch V2 11/28] x86/speculation: Rework SMT state change
arch_smt_update() is only called when the sysfs SMT control knob is
changed. This means that when SMT is enabled in the sysfs control knob the
system is considered to have SMT active even if all siblings are offline.
To allow finegrained control of the speculation mitigations, the actual SMT
state is more interesting than the fact that siblings could be enabled.
Rework the code, so arch_smt_update() is invoked from each individual CPU
hotplug function, and simplify the update function while at it.
Signed-off-by: Thomas Gleixner
---
v1 -> v2: Adapt to new header sched/smt.h
---
arch/x86/kernel/cpu/bugs.c | 11 +--
include/linux/sched/smt.h |2 ++
kernel/cpu.c | 15 +--
3 files changed, 16 insertions(+), 12 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -344,16 +345,14 @@ void arch_smt_update(void)
return;
mutex_lock(_ctrl_mutex);
- mask = x86_spec_ctrl_base;
- if (cpu_smt_control == CPU_SMT_ENABLED)
+
+ mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
+ if (sched_smt_active())
mask |= SPEC_CTRL_STIBP;
- else
- mask &= ~SPEC_CTRL_STIBP;
if (mask != x86_spec_ctrl_base) {
pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
- cpu_smt_control == CPU_SMT_ENABLED ?
- "Enabling" : "Disabling");
+ mask & SPEC_CTRL_STIBP ? "Enabling" : "Disabling");
x86_spec_ctrl_base = mask;
on_each_cpu(update_stibp_msr, NULL, 1);
}
--- a/include/linux/sched/smt.h
+++ b/include/linux/sched/smt.h
@@ -15,4 +15,6 @@ static __always_inline bool sched_smt_ac
static inline bool sched_smt_active(void) { return false; }
#endif
+void arch_smt_update(void);
+
#endif
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -367,6 +368,12 @@ static void lockdep_release_cpus_lock(vo
#endif /* CONFIG_HOTPLUG_CPU */
+/*
+ * Architectures that need SMT-specific errata handling during SMT hotplug
+ * should override this.
+ */
+void __weak arch_smt_update(void) { }
+
#ifdef CONFIG_HOTPLUG_SMT
enum cpuhp_smt_control cpu_smt_control __read_mostly = CPU_SMT_ENABLED;
EXPORT_SYMBOL_GPL(cpu_smt_control);
@@ -1011,6 +1018,7 @@ static int __ref _cpu_down(unsigned int
* concurrent CPU hotplug via cpu_add_remove_lock.
*/
lockup_detector_cleanup();
+ arch_smt_update();
return ret;
}
@@ -1139,6 +1147,7 @@ static int _cpu_up(unsigned int cpu, int
ret = cpuhp_up_callbacks(cpu, st, target);
out:
cpus_write_unlock();
+ arch_smt_update();
return ret;
}
@@ -2055,12 +2064,6 @@ static void cpuhp_online_cpu_device(unsi
kobject_uevent(>kobj, KOBJ_ONLINE);
}
-/*
- * Architectures that need SMT-specific errata handling during SMT hotplug
- * should override this.
- */
-void __weak arch_smt_update(void) { };
-
static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Sun, Nov 25, 2018 at 08:22:35AM -0800, Andy Lutomirski wrote: Good morning to everyone, I hope the weekend continues to proceed well. Proposal follows below for kernel based policy management of enclaves if people want to skip forward. > >> On Nov 25, 2018, at 6:53 AM, Jarkko Sakkinen > >> wrote: > >> > >> On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: > >> On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > At a high level, addressing these issues is straight forward. First, > the driver needs to support authorization equivalent to that which is > implemented in the current Intel Launch Enclave, ie. control over the > SGX_FLAGS_PROVISION_KEY attribute. > >>> > >>> I agree, hence my email :) > >> > >> Started to scratch my head that is it really an issue that any enclave > >> can provision in the end? > >> > >> Direct quote from your first response: > >> > >> "In particular, the ability to run enclaves with the provisioning bit set > >> is somewhat sensitive, since it effectively allows access to a stable > >> fingerprint of the system." > >> > >> As can be seen from the key derivation table this does not exactly hold > >> so you should refine your original argument before we can consider any > >> type of change. > >> > >> I just don't see what it is so wrong for any enclave to be able to tell > >> that it really is an enclave. > > I mean I can understand why Greg wants LE although I don't understand > > what benefit does it bring to anyone to lock in for enclave to allow > > to identify itself. > > > > What you are proposing does not really bring any additional security if > > we consider a threat model where the kernel is an adversary but it makes > > the software stack more clanky to use. > Agreed. What I'm proposing adds additional security if the kernel is > *not* compromised. Let me use this to stress a concept that I believe is important in this discussion. SGX is enabling technology that allows developers to create software architectures that will deliver their stated security and privacy guarantees irrespective of platform state. It does this by linking 'islands' of execution (enclaves) together through a web of cryptographic guarantees. The notion of a launch enclave is critical to establishing these guarantees. As soon as the kernel becomes involved in implementing SGX security policy the architecture becomes vulnerable to kernel and/or privilege modification attacks. We've talked at length about the provisioning bit, I won't go into details unless people are interested, but the EPID provisioning protocol implements an SGX mediated cryptographic contract that a perpetual platform identifier will not be disclosed to anyone but Intel. The launch enclave is critical to that guarantee. It is completely understandable why a locked down, (non-FLC) hardware platform, is undesirable in this community. That doesn't mean that a launch enclave as a concept is unneeded or necessarily evil. In an FLC environment the kernel assumes responsibility for SGX privacy and security. This means that we need to do at least as well with a kernel based model as to what is currently available. > There are other ways to accomplish it that might be better in some > respects. For example, there could be /dev/sgx and > /dev/sgx_rights/provision. The former exposes the whole sgx API, > except that it doesn???t allow provisioning by default. The latter > does nothing by itself. To run a provisioning enclave, you open both > nodes, then do something like: > > ioctl(sgx, SGX_IOC_ADD_RIGHT, sgx_provisioning); > > This requires extra syscalls, but it doesn't have the combinatorial > explosion problem. Here is a proposal for the driver to add the needed policy control that is 'SGXy' in nature. The 'SGXy' way is to use MRSIGNER values as the currency for security policy management. The driver should establish the equivalent of three linked lists, maintainable via /sysfs pseudo-files or equivalent plumbing. The lists are referenced by the kernel to enforce the following policies. 1.) The right to initialize an enclave without special attributes. 2.) The right to initialize an enclave with the PROVISION_KEY attribute set. 3.) The right to initialize an enclave with the LICENSE_KEY attribute set. The lists are populated with MRSIGNER values of enclaves that are allowed to initialize under the specified conditions. The driver should either establish a 'seal' file or value, ie. MRSIGNER value of all zero's, that once written will not allow further modifications of the list(s). This will allow cryptographically guaranteed policies to be setup at early boot that will limit the ability of subsequent DAC compromises to affect policy management. The lists are obviously vulnerable to a kernel compromise but the vulnerability scope is significantly limited vs. 'can I get root or some other userid'. If we are really concerned about the scope of
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Sun, Nov 25, 2018 at 08:22:35AM -0800, Andy Lutomirski wrote: Good morning to everyone, I hope the weekend continues to proceed well. Proposal follows below for kernel based policy management of enclaves if people want to skip forward. > >> On Nov 25, 2018, at 6:53 AM, Jarkko Sakkinen > >> wrote: > >> > >> On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: > >> On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > At a high level, addressing these issues is straight forward. First, > the driver needs to support authorization equivalent to that which is > implemented in the current Intel Launch Enclave, ie. control over the > SGX_FLAGS_PROVISION_KEY attribute. > >>> > >>> I agree, hence my email :) > >> > >> Started to scratch my head that is it really an issue that any enclave > >> can provision in the end? > >> > >> Direct quote from your first response: > >> > >> "In particular, the ability to run enclaves with the provisioning bit set > >> is somewhat sensitive, since it effectively allows access to a stable > >> fingerprint of the system." > >> > >> As can be seen from the key derivation table this does not exactly hold > >> so you should refine your original argument before we can consider any > >> type of change. > >> > >> I just don't see what it is so wrong for any enclave to be able to tell > >> that it really is an enclave. > > I mean I can understand why Greg wants LE although I don't understand > > what benefit does it bring to anyone to lock in for enclave to allow > > to identify itself. > > > > What you are proposing does not really bring any additional security if > > we consider a threat model where the kernel is an adversary but it makes > > the software stack more clanky to use. > Agreed. What I'm proposing adds additional security if the kernel is > *not* compromised. Let me use this to stress a concept that I believe is important in this discussion. SGX is enabling technology that allows developers to create software architectures that will deliver their stated security and privacy guarantees irrespective of platform state. It does this by linking 'islands' of execution (enclaves) together through a web of cryptographic guarantees. The notion of a launch enclave is critical to establishing these guarantees. As soon as the kernel becomes involved in implementing SGX security policy the architecture becomes vulnerable to kernel and/or privilege modification attacks. We've talked at length about the provisioning bit, I won't go into details unless people are interested, but the EPID provisioning protocol implements an SGX mediated cryptographic contract that a perpetual platform identifier will not be disclosed to anyone but Intel. The launch enclave is critical to that guarantee. It is completely understandable why a locked down, (non-FLC) hardware platform, is undesirable in this community. That doesn't mean that a launch enclave as a concept is unneeded or necessarily evil. In an FLC environment the kernel assumes responsibility for SGX privacy and security. This means that we need to do at least as well with a kernel based model as to what is currently available. > There are other ways to accomplish it that might be better in some > respects. For example, there could be /dev/sgx and > /dev/sgx_rights/provision. The former exposes the whole sgx API, > except that it doesn???t allow provisioning by default. The latter > does nothing by itself. To run a provisioning enclave, you open both > nodes, then do something like: > > ioctl(sgx, SGX_IOC_ADD_RIGHT, sgx_provisioning); > > This requires extra syscalls, but it doesn't have the combinatorial > explosion problem. Here is a proposal for the driver to add the needed policy control that is 'SGXy' in nature. The 'SGXy' way is to use MRSIGNER values as the currency for security policy management. The driver should establish the equivalent of three linked lists, maintainable via /sysfs pseudo-files or equivalent plumbing. The lists are referenced by the kernel to enforce the following policies. 1.) The right to initialize an enclave without special attributes. 2.) The right to initialize an enclave with the PROVISION_KEY attribute set. 3.) The right to initialize an enclave with the LICENSE_KEY attribute set. The lists are populated with MRSIGNER values of enclaves that are allowed to initialize under the specified conditions. The driver should either establish a 'seal' file or value, ie. MRSIGNER value of all zero's, that once written will not allow further modifications of the list(s). This will allow cryptographically guaranteed policies to be setup at early boot that will limit the ability of subsequent DAC compromises to affect policy management. The lists are obviously vulnerable to a kernel compromise but the vulnerability scope is significantly limited vs. 'can I get root or some other userid'. If we are really concerned about the scope of
Re: [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
On Sat, Nov 24, 2018 at 7:21 PM Hugh Dickins wrote: > > Linus, I'm addressing this patch to you because I see from Tim Chen's > thread that it would interest you, and you were disappointed not to > root cause the issue back then. I'm not pushing for you to fast-track > this into 4.20-rc, but I expect Andrew will pick it up for mmotm, and > thence linux-next. Or you may spot a terrible defect, but I hope not. The only terrible defect I spot is that I wish the change to the 'lock' argument in wait_on_page_bit_common() came with a comment explaining the new semantics. The old semantics were somewhat obvious (even if not documented): if 'lock' was set, we'd make the wait exclusive, and we'd lock the page before returning. That kind of matches the intuitive meaning for the function prototype, and it's pretty obvious in the callers too. The new semantics don't have the same kind of really intuitive meaning, I feel. That "-1" doesn't mean "unlock", it means "drop page reference", so there is no longer a fairly intuitive and direct mapping between the argument name and type and the behavior of the function. So I don't hate the concept of the patch at all, but I do ask to: - better documentation. This might not be "documentation" at all, maybe that "lock" variable should just be renamed (because it's not about just locking any more), and would be better off as a tristate enum called "behavior" that has "LOCK, DROP, WAIT" values? - while it sounds likely that this is indeed the same issue that plagues us with the insanely long wait-queues, it would be *really* nice to have that actually confirmed. Does somebody still have access to the customer load that triggered the horrible scaling issues before? In particular, on that second issue: the "fixes" that went in for the wait-queues didn't really fix any real scalability problem, it really just fixed the excessive irq latency issues due to the long traversal holding a lock. If this really fixes the fundamental issue, that should show up as an actual performance difference, I'd expect.. End result: I like and approve of the patch, but I'd like it a lot more if the code behavior was clarified a bit, and I'd really like to close the loop on that old nasty page wait queue issue... Linus
Re: [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
On Sat, Nov 24, 2018 at 7:21 PM Hugh Dickins wrote: > > Linus, I'm addressing this patch to you because I see from Tim Chen's > thread that it would interest you, and you were disappointed not to > root cause the issue back then. I'm not pushing for you to fast-track > this into 4.20-rc, but I expect Andrew will pick it up for mmotm, and > thence linux-next. Or you may spot a terrible defect, but I hope not. The only terrible defect I spot is that I wish the change to the 'lock' argument in wait_on_page_bit_common() came with a comment explaining the new semantics. The old semantics were somewhat obvious (even if not documented): if 'lock' was set, we'd make the wait exclusive, and we'd lock the page before returning. That kind of matches the intuitive meaning for the function prototype, and it's pretty obvious in the callers too. The new semantics don't have the same kind of really intuitive meaning, I feel. That "-1" doesn't mean "unlock", it means "drop page reference", so there is no longer a fairly intuitive and direct mapping between the argument name and type and the behavior of the function. So I don't hate the concept of the patch at all, but I do ask to: - better documentation. This might not be "documentation" at all, maybe that "lock" variable should just be renamed (because it's not about just locking any more), and would be better off as a tristate enum called "behavior" that has "LOCK, DROP, WAIT" values? - while it sounds likely that this is indeed the same issue that plagues us with the insanely long wait-queues, it would be *really* nice to have that actually confirmed. Does somebody still have access to the customer load that triggered the horrible scaling issues before? In particular, on that second issue: the "fixes" that went in for the wait-queues didn't really fix any real scalability problem, it really just fixed the excessive irq latency issues due to the long traversal holding a lock. If this really fixes the fundamental issue, that should show up as an actual performance difference, I'd expect.. End result: I like and approve of the patch, but I'd like it a lot more if the code behavior was clarified a bit, and I'd really like to close the loop on that old nasty page wait queue issue... Linus
[PATCH] clk: rockchip: add clock ID of ACODEC for rk3328
This patch adds clock ID of audio CODEC (ACODEC) for rk3328. Signed-off-by: Katsuhiro Suzuki --- include/dt-bindings/clock/rk3328-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/rk3328-cru.h b/include/dt-bindings/clock/rk3328-cru.h index 9d5f799469ee..bcaa4559ab1b 100644 --- a/include/dt-bindings/clock/rk3328-cru.h +++ b/include/dt-bindings/clock/rk3328-cru.h @@ -172,6 +172,7 @@ #define PCLK_HDCP 232 #define PCLK_DCF 233 #define PCLK_SARADC234 +#define PCLK_ACODECPHY 235 /* hclk gates */ #define HCLK_PERI 308 -- 2.19.1
[PATCH] clk: rockchip: add clock gate of ACODEC for rk3328
This patch adds small changes into clock gate definition to enable
ACODEC for rk3328.
Signed-off-by: Katsuhiro Suzuki
---
drivers/clk/rockchip/clk-rk3328.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3328.c
b/drivers/clk/rockchip/clk-rk3328.c
index 1eb46aa8b2fa..faa94adb2a37 100644
--- a/drivers/clk/rockchip/clk-rk3328.c
+++ b/drivers/clk/rockchip/clk-rk3328.c
@@ -804,7 +804,7 @@ static struct rockchip_clk_branch rk3328_clk_branches[]
__initdata = {
GATE(PCLK_USB3_GRF, "pclk_usb3_grf", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 2, GFLAGS),
GATE(PCLK_USB2_GRF, "pclk_usb2_grf", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 14, GFLAGS),
GATE(0, "pclk_ddrphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 13, GFLAGS),
- GATE(0, "pclk_acodecphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 5, GFLAGS),
+ GATE(PCLK_ACODECPHY, "pclk_acodecphy", "pclk_phy_pre", 0,
RK3328_CLKGATE_CON(17), 5, GFLAGS),
GATE(PCLK_HDMIPHY, "pclk_hdmiphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 7, GFLAGS),
GATE(0, "pclk_vdacphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 8, GFLAGS),
GATE(0, "pclk_phy_niu", "pclk_phy_pre", 0, RK3328_CLKGATE_CON(15), 15,
GFLAGS),
--
2.19.1
[PATCH] clk: rockchip: add clock ID of ACODEC for rk3328
This patch adds clock ID of audio CODEC (ACODEC) for rk3328. Signed-off-by: Katsuhiro Suzuki --- include/dt-bindings/clock/rk3328-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/rk3328-cru.h b/include/dt-bindings/clock/rk3328-cru.h index 9d5f799469ee..bcaa4559ab1b 100644 --- a/include/dt-bindings/clock/rk3328-cru.h +++ b/include/dt-bindings/clock/rk3328-cru.h @@ -172,6 +172,7 @@ #define PCLK_HDCP 232 #define PCLK_DCF 233 #define PCLK_SARADC234 +#define PCLK_ACODECPHY 235 /* hclk gates */ #define HCLK_PERI 308 -- 2.19.1
[PATCH] clk: rockchip: add clock gate of ACODEC for rk3328
This patch adds small changes into clock gate definition to enable
ACODEC for rk3328.
Signed-off-by: Katsuhiro Suzuki
---
drivers/clk/rockchip/clk-rk3328.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3328.c
b/drivers/clk/rockchip/clk-rk3328.c
index 1eb46aa8b2fa..faa94adb2a37 100644
--- a/drivers/clk/rockchip/clk-rk3328.c
+++ b/drivers/clk/rockchip/clk-rk3328.c
@@ -804,7 +804,7 @@ static struct rockchip_clk_branch rk3328_clk_branches[]
__initdata = {
GATE(PCLK_USB3_GRF, "pclk_usb3_grf", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 2, GFLAGS),
GATE(PCLK_USB2_GRF, "pclk_usb2_grf", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 14, GFLAGS),
GATE(0, "pclk_ddrphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 13, GFLAGS),
- GATE(0, "pclk_acodecphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 5, GFLAGS),
+ GATE(PCLK_ACODECPHY, "pclk_acodecphy", "pclk_phy_pre", 0,
RK3328_CLKGATE_CON(17), 5, GFLAGS),
GATE(PCLK_HDMIPHY, "pclk_hdmiphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 7, GFLAGS),
GATE(0, "pclk_vdacphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 8, GFLAGS),
GATE(0, "pclk_phy_niu", "pclk_phy_pre", 0, RK3328_CLKGATE_CON(15), 15,
GFLAGS),
--
2.19.1
[PATCH] KVM: x86: Trace changes to active TSC offset regardless if vCPU in guest-mode
For some reason, kvm_x86_ops->write_l1_tsc_offset() skipped trace
of change to active TSC offset in case vCPU is in guest-mode.
This patch changes write_l1_tsc_offset() behavior to trace any change
to active TSC offset to aid debugging. The VMX code is changed to
look more similar to SVM, which is in my opinion nicer.
Based on a patch by Liran Alon.
Signed-off-by: Paolo Bonzini
---
Untested still, but throwing it out because it seems pretty
obvious...
arch/x86/kvm/svm.c | 9 +
arch/x86/kvm/vmx.c | 34 +-
2 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index a24733aade4c..0d1a74069a9e 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1456,10 +1456,11 @@ static u64 svm_write_l1_tsc_offset(struct kvm_vcpu
*vcpu, u64 offset)
g_tsc_offset = svm->vmcb->control.tsc_offset -
svm->nested.hsave->control.tsc_offset;
svm->nested.hsave->control.tsc_offset = offset;
- } else
- trace_kvm_write_tsc_offset(vcpu->vcpu_id,
- svm->vmcb->control.tsc_offset,
- offset);
+ }
+
+ trace_kvm_write_tsc_offset(vcpu->vcpu_id,
+ svm->vmcb->control.tsc_offset - g_tsc_offset,
+ offset);
svm->vmcb->control.tsc_offset = offset + g_tsc_offset;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 764c23dc444f..e7d3f7d35355 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3466,24 +3466,24 @@ static u64 vmx_read_l1_tsc_offset(struct kvm_vcpu *vcpu)
static u64 vmx_write_l1_tsc_offset(struct kvm_vcpu *vcpu, u64 offset)
{
- u64 active_offset = offset;
- if (is_guest_mode(vcpu)) {
- /*
-* We're here if L1 chose not to trap WRMSR to TSC. According
-* to the spec, this should set L1's TSC; The offset that L1
-* set for L2 remains unchanged, and still needs to be added
-* to the newly set TSC to get L2's TSC.
-*/
- struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
- if (nested_cpu_has(vmcs12, CPU_BASED_USE_TSC_OFFSETING))
- active_offset += vmcs12->tsc_offset;
- } else {
- trace_kvm_write_tsc_offset(vcpu->vcpu_id,
- vmcs_read64(TSC_OFFSET), offset);
- }
+ struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
+ u64 g_tsc_offset = 0;
+
+ /*
+* We're here if L1 chose not to trap WRMSR to TSC. According
+* to the spec, this should set L1's TSC; The offset that L1
+* set for L2 remains unchanged, and still needs to be added
+* to the newly set TSC to get L2's TSC.
+*/
+ if (is_guest_mode(vcpu) &&
+ (vmcs12->cpu_based_vm_exec_control & CPU_BASED_USE_TSC_OFFSETING))
+ g_tsc_offset = vmcs12->tsc_offset;
- vmcs_write64(TSC_OFFSET, active_offset);
- return active_offset;
+ trace_kvm_write_tsc_offset(vcpu->vcpu_id,
+ vcpu->arch.tsc_offset - g_tsc_offset,
+ offset);
+ vmcs_write64(TSC_OFFSET, offset + g_tsc_offset);
+ return offset + g_tsc_offset;
}
/*
--
1.8.3.1
[PATCH] KVM: x86: Trace changes to active TSC offset regardless if vCPU in guest-mode
For some reason, kvm_x86_ops->write_l1_tsc_offset() skipped trace
of change to active TSC offset in case vCPU is in guest-mode.
This patch changes write_l1_tsc_offset() behavior to trace any change
to active TSC offset to aid debugging. The VMX code is changed to
look more similar to SVM, which is in my opinion nicer.
Based on a patch by Liran Alon.
Signed-off-by: Paolo Bonzini
---
Untested still, but throwing it out because it seems pretty
obvious...
arch/x86/kvm/svm.c | 9 +
arch/x86/kvm/vmx.c | 34 +-
2 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index a24733aade4c..0d1a74069a9e 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1456,10 +1456,11 @@ static u64 svm_write_l1_tsc_offset(struct kvm_vcpu
*vcpu, u64 offset)
g_tsc_offset = svm->vmcb->control.tsc_offset -
svm->nested.hsave->control.tsc_offset;
svm->nested.hsave->control.tsc_offset = offset;
- } else
- trace_kvm_write_tsc_offset(vcpu->vcpu_id,
- svm->vmcb->control.tsc_offset,
- offset);
+ }
+
+ trace_kvm_write_tsc_offset(vcpu->vcpu_id,
+ svm->vmcb->control.tsc_offset - g_tsc_offset,
+ offset);
svm->vmcb->control.tsc_offset = offset + g_tsc_offset;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 764c23dc444f..e7d3f7d35355 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3466,24 +3466,24 @@ static u64 vmx_read_l1_tsc_offset(struct kvm_vcpu *vcpu)
static u64 vmx_write_l1_tsc_offset(struct kvm_vcpu *vcpu, u64 offset)
{
- u64 active_offset = offset;
- if (is_guest_mode(vcpu)) {
- /*
-* We're here if L1 chose not to trap WRMSR to TSC. According
-* to the spec, this should set L1's TSC; The offset that L1
-* set for L2 remains unchanged, and still needs to be added
-* to the newly set TSC to get L2's TSC.
-*/
- struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
- if (nested_cpu_has(vmcs12, CPU_BASED_USE_TSC_OFFSETING))
- active_offset += vmcs12->tsc_offset;
- } else {
- trace_kvm_write_tsc_offset(vcpu->vcpu_id,
- vmcs_read64(TSC_OFFSET), offset);
- }
+ struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
+ u64 g_tsc_offset = 0;
+
+ /*
+* We're here if L1 chose not to trap WRMSR to TSC. According
+* to the spec, this should set L1's TSC; The offset that L1
+* set for L2 remains unchanged, and still needs to be added
+* to the newly set TSC to get L2's TSC.
+*/
+ if (is_guest_mode(vcpu) &&
+ (vmcs12->cpu_based_vm_exec_control & CPU_BASED_USE_TSC_OFFSETING))
+ g_tsc_offset = vmcs12->tsc_offset;
- vmcs_write64(TSC_OFFSET, active_offset);
- return active_offset;
+ trace_kvm_write_tsc_offset(vcpu->vcpu_id,
+ vcpu->arch.tsc_offset - g_tsc_offset,
+ offset);
+ vmcs_write64(TSC_OFFSET, offset + g_tsc_offset);
+ return offset + g_tsc_offset;
}
/*
--
1.8.3.1
Re: [GIT PULL] Please pull NFS client changes
The pull request you sent on Sun, 25 Nov 2018 03:04:11 +: > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.20-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/17c2f540863a6c0faa3f0ede3c785d9427bcaf80 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull NFS client changes
The pull request you sent on Sun, 25 Nov 2018 03:04:11 +: > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.20-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/17c2f540863a6c0faa3f0ede3c785d9427bcaf80 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] XArray updates
The pull request you sent on Sat, 24 Nov 2018 09:32:09 -0800: > git://git.infradead.org/users/willy/linux-dax.git xarray has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e2125dac22f2c9c66c412cd8e049a7305af59f73 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] dma-mapping fixes for 4.20
The pull request you sent on Sun, 25 Nov 2018 09:35:52 +0100: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.20-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d6d460b89378b1bc6715574cdafd748ba59d5a27 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] XArray updates
The pull request you sent on Sat, 24 Nov 2018 09:32:09 -0800: > git://git.infradead.org/users/willy/linux-dax.git xarray has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e2125dac22f2c9c66c412cd8e049a7305af59f73 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] dma-mapping fixes for 4.20
The pull request you sent on Sun, 25 Nov 2018 09:35:52 +0100: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.20-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d6d460b89378b1bc6715574cdafd748ba59d5a27 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] x86/kvm/vmx: fix old-style function declaration
On 08/11/18 04:22, Yi Wang wrote:
> The inline keyword which is not at the beginning of the function
> declaration may trigger the following build warnings, so let's fix it:
>
> arch/x86/kvm/vmx.c:1309:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
> arch/x86/kvm/vmx.c:5947:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
> arch/x86/kvm/vmx.c:5985:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
> arch/x86/kvm/vmx.c:6023:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
>
> Signed-off-by: Yi Wang
> ---
> arch/x86/kvm/vmx.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 4555077..cd8355b 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -1306,7 +1306,7 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
> static bool nested_vmx_is_page_fault_vmexit(struct vmcs12 *vmcs12,
> u16 error_code);
> static void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
> -static void __always_inline vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> u32 msr, int type);
>
> static DEFINE_PER_CPU(struct vmcs *, vmxarea);
> @@ -5944,7 +5944,7 @@ static void free_vpid(int vpid)
> spin_unlock(_vpid_lock);
> }
>
> -static void __always_inline vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> u32 msr, int type)
> {
> int f = sizeof(unsigned long);
> @@ -5982,7 +5982,7 @@ static void __always_inline
> vmx_disable_intercept_for_msr(unsigned long *msr_bit
> }
> }
>
> -static void __always_inline vmx_enable_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_enable_intercept_for_msr(unsigned long
> *msr_bitmap,
>u32 msr, int type)
> {
> int f = sizeof(unsigned long);
> @@ -6020,7 +6020,7 @@ static void __always_inline
> vmx_enable_intercept_for_msr(unsigned long *msr_bitm
> }
> }
>
> -static void __always_inline vmx_set_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_set_intercept_for_msr(unsigned long
> *msr_bitmap,
> u32 msr, int type, bool
> value)
> {
> if (value)
>
Queued, thanks.
Paolo
Re: [PATCH] x86/kvm/vmx: fix old-style function declaration
On 08/11/18 04:22, Yi Wang wrote:
> The inline keyword which is not at the beginning of the function
> declaration may trigger the following build warnings, so let's fix it:
>
> arch/x86/kvm/vmx.c:1309:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
> arch/x86/kvm/vmx.c:5947:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
> arch/x86/kvm/vmx.c:5985:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
> arch/x86/kvm/vmx.c:6023:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
>
> Signed-off-by: Yi Wang
> ---
> arch/x86/kvm/vmx.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 4555077..cd8355b 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -1306,7 +1306,7 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
> static bool nested_vmx_is_page_fault_vmexit(struct vmcs12 *vmcs12,
> u16 error_code);
> static void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
> -static void __always_inline vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> u32 msr, int type);
>
> static DEFINE_PER_CPU(struct vmcs *, vmxarea);
> @@ -5944,7 +5944,7 @@ static void free_vpid(int vpid)
> spin_unlock(_vpid_lock);
> }
>
> -static void __always_inline vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> u32 msr, int type)
> {
> int f = sizeof(unsigned long);
> @@ -5982,7 +5982,7 @@ static void __always_inline
> vmx_disable_intercept_for_msr(unsigned long *msr_bit
> }
> }
>
> -static void __always_inline vmx_enable_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_enable_intercept_for_msr(unsigned long
> *msr_bitmap,
>u32 msr, int type)
> {
> int f = sizeof(unsigned long);
> @@ -6020,7 +6020,7 @@ static void __always_inline
> vmx_enable_intercept_for_msr(unsigned long *msr_bitm
> }
> }
>
> -static void __always_inline vmx_set_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_set_intercept_for_msr(unsigned long
> *msr_bitmap,
> u32 msr, int type, bool
> value)
> {
> if (value)
>
Queued, thanks.
Paolo
Re: [PATCH] KVM: x86: fix empty-body warnings
On 08/11/18 09:48, Yi Wang wrote:
> We get the following warnings about empty statements when building
> with 'W=1':
>
> arch/x86/kvm/lapic.c:632:53: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
> arch/x86/kvm/lapic.c:1907:42: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
> arch/x86/kvm/lapic.c:1936:65: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
> arch/x86/kvm/lapic.c:1975:44: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
>
> Rework the debug helper macro to get rid of these warnings.
>
> Signed-off-by: Yi Wang
> ---
> arch/x86/kvm/lapic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 89db20f..53b8c8e 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -55,7 +55,7 @@
> #define PRIo64 "o"
>
> /* #define apic_debug(fmt,arg...) printk(KERN_WARNING fmt,##arg) */
> -#define apic_debug(fmt, arg...)
> +#define apic_debug(fmt, arg...) do {} while (0)
>
> /* 14 is the version for Xeon and Pentium 8.4.8*/
> #define APIC_VERSION (0x14UL | ((KVM_APIC_LVT_NUM - 1) <<
> 16))
>
Queued, thanks.
Paolo
Re: [PATCH] svm: Add mutex_lock to protect apic_access_page_done on AMD systems
On 12/11/18 14:37, j...@8bytes.org wrote: > On Mon, Nov 12, 2018 at 12:23:14PM +, Suthikulpanit, Suravee wrote: >> From: Wei Wang >> >> There is a race condition when accessing kvm->arch.apic_access_page_done. >> Due to it, x86_set_memory_region will fail when creating the second vcpu >> for a svm guest. >> >> Add a mutex_lock to serialize the accesses to apic_access_page_done. >> This lock is also used by vmx for the same purpose. >> >> Signed-off-by: Wei Wang >> Signed-off-by: Amadeusz Juskowiak >> Signed-off-by: Julian Stecklina >> Signed-off-by: Suravee Suthikulpanit > Reviewed-by: Joerg Roedel Queued, thanks. Paolo
Re: [PATCH] KVM: x86: fix empty-body warnings
On 08/11/18 09:48, Yi Wang wrote:
> We get the following warnings about empty statements when building
> with 'W=1':
>
> arch/x86/kvm/lapic.c:632:53: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
> arch/x86/kvm/lapic.c:1907:42: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
> arch/x86/kvm/lapic.c:1936:65: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
> arch/x86/kvm/lapic.c:1975:44: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
>
> Rework the debug helper macro to get rid of these warnings.
>
> Signed-off-by: Yi Wang
> ---
> arch/x86/kvm/lapic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 89db20f..53b8c8e 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -55,7 +55,7 @@
> #define PRIo64 "o"
>
> /* #define apic_debug(fmt,arg...) printk(KERN_WARNING fmt,##arg) */
> -#define apic_debug(fmt, arg...)
> +#define apic_debug(fmt, arg...) do {} while (0)
>
> /* 14 is the version for Xeon and Pentium 8.4.8*/
> #define APIC_VERSION (0x14UL | ((KVM_APIC_LVT_NUM - 1) <<
> 16))
>
Queued, thanks.
Paolo
Re: [PATCH] svm: Add mutex_lock to protect apic_access_page_done on AMD systems
On 12/11/18 14:37, j...@8bytes.org wrote: > On Mon, Nov 12, 2018 at 12:23:14PM +, Suthikulpanit, Suravee wrote: >> From: Wei Wang >> >> There is a race condition when accessing kvm->arch.apic_access_page_done. >> Due to it, x86_set_memory_region will fail when creating the second vcpu >> for a svm guest. >> >> Add a mutex_lock to serialize the accesses to apic_access_page_done. >> This lock is also used by vmx for the same purpose. >> >> Signed-off-by: Wei Wang >> Signed-off-by: Amadeusz Juskowiak >> Signed-off-by: Julian Stecklina >> Signed-off-by: Suravee Suthikulpanit > Reviewed-by: Joerg Roedel Queued, thanks. Paolo
Re: [PATCH] KVM: LAPIC: Fix pv ipis use-before-initialization
On 20/11/18 02:39, Wanpeng Li wrote:
> Reported by syzkaller:
>
> BUG: unable to handle kernel NULL pointer dereference at 0014
> PGD 80040410c067 P4D 80040410c067 PUD 40410d067 PMD 0
> Oops: [#1] PREEMPT SMP PTI
> CPU: 3 PID: 2567 Comm: poc Tainted: G OE 4.19.0-rc5 #16
> RIP: 0010:kvm_pv_send_ipi+0x94/0x350 [kvm]
> Call Trace:
> kvm_emulate_hypercall+0x3cc/0x700 [kvm]
> handle_vmcall+0xe/0x10 [kvm_intel]
> vmx_handle_exit+0xc1/0x11b0 [kvm_intel]
> vcpu_enter_guest+0x9fb/0x1910 [kvm]
> kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
> kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
> do_vfs_ioctl+0xa5/0x690
> ksys_ioctl+0x6d/0x80
> __x64_sys_ioctl+0x1a/0x20
> do_syscall_64+0x83/0x6e0
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The reason is that the apic map has not yet been initialized, the testcase
> triggers pv_send_ipi interface by vmcall which results in kvm->arch.apic_map
> is dereferenced. This patch fixes it by checking whether or not apic map is
> NULL and bailing out immediately if that is the case.
>
> Fixes: 4180bf1b65 (KVM: X86: Implement "send IPI" hypercall)
> Reported-by: Wei Wu
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Wei Wu
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/lapic.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 3cd227f..09e3a12 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -576,6 +576,11 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long
> ipi_bitmap_low,
> rcu_read_lock();
> map = rcu_dereference(kvm->arch.apic_map);
>
> + if (unlikely(!map)) {
> + count = -EOPNOTSUPP;
> + goto out;
> + }
> +
> if (min > map->max_apic_id)
> goto out;
> /* Bits above cluster_size are masked in the caller. */
>
Queued, thanks.
Paolo
Re: [PATCH] KVM: LAPIC: Fix pv ipis use-before-initialization
On 20/11/18 02:39, Wanpeng Li wrote:
> Reported by syzkaller:
>
> BUG: unable to handle kernel NULL pointer dereference at 0014
> PGD 80040410c067 P4D 80040410c067 PUD 40410d067 PMD 0
> Oops: [#1] PREEMPT SMP PTI
> CPU: 3 PID: 2567 Comm: poc Tainted: G OE 4.19.0-rc5 #16
> RIP: 0010:kvm_pv_send_ipi+0x94/0x350 [kvm]
> Call Trace:
> kvm_emulate_hypercall+0x3cc/0x700 [kvm]
> handle_vmcall+0xe/0x10 [kvm_intel]
> vmx_handle_exit+0xc1/0x11b0 [kvm_intel]
> vcpu_enter_guest+0x9fb/0x1910 [kvm]
> kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
> kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
> do_vfs_ioctl+0xa5/0x690
> ksys_ioctl+0x6d/0x80
> __x64_sys_ioctl+0x1a/0x20
> do_syscall_64+0x83/0x6e0
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The reason is that the apic map has not yet been initialized, the testcase
> triggers pv_send_ipi interface by vmcall which results in kvm->arch.apic_map
> is dereferenced. This patch fixes it by checking whether or not apic map is
> NULL and bailing out immediately if that is the case.
>
> Fixes: 4180bf1b65 (KVM: X86: Implement "send IPI" hypercall)
> Reported-by: Wei Wu
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Wei Wu
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/lapic.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 3cd227f..09e3a12 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -576,6 +576,11 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long
> ipi_bitmap_low,
> rcu_read_lock();
> map = rcu_dereference(kvm->arch.apic_map);
>
> + if (unlikely(!map)) {
> + count = -EOPNOTSUPP;
> + goto out;
> + }
> +
> if (min > map->max_apic_id)
> goto out;
> /* Bits above cluster_size are masked in the caller. */
>
Queued, thanks.
Paolo
Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization
On 20/11/18 09:34, Wanpeng Li wrote:
> From: Wanpeng Li
>
> Reported by syzkaller:
>
> BUG: unable to handle kernel NULL pointer dereference at 01c8
> PGD 8003ec4da067 P4D 8003ec4da067 PUD 3f7bfa067 PMD 0
> Oops: [#1] PREEMPT SMP PTI
> CPU: 7 PID: 5059 Comm: debug Tainted: G OE 4.19.0-rc5 #16
> RIP: 0010:__lock_acquire+0x1a6/0x1990
> Call Trace:
> lock_acquire+0xdb/0x210
> _raw_spin_lock+0x38/0x70
> kvm_ioapic_scan_entry+0x3e/0x110 [kvm]
> vcpu_enter_guest+0x167e/0x1910 [kvm]
> kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
> kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
> do_vfs_ioctl+0xa5/0x690
> ksys_ioctl+0x6d/0x80
> __x64_sys_ioctl+0x1a/0x20
> do_syscall_64+0x83/0x6e0
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The reason is that the testcase writes hyperv synic HV_X64_MSR_SINT6 msr
> and triggers scan ioapic logic to load synic vectors into EOI exit bitmap.
> However, irqchip is not initialized by this simple testcase, ioapic/apic
> objects should not be accessed.
> This can be triggered by the following program:
>
> #define _GNU_SOURCE
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> uint64_t r[3] = {0x, 0x,
> 0x};
>
> int main(void)
> {
> syscall(__NR_mmap, 0x2000, 0x100, 3, 0x32, -1, 0);
> long res = 0;
> memcpy((void*)0x2040, "/dev/kvm", 9);
> res = syscall(__NR_openat, 0xff9c, 0x2040, 0, 0);
> if (res != -1)
> r[0] = res;
> res = syscall(__NR_ioctl, r[0], 0xae01, 0);
> if (res != -1)
> r[1] = res;
> res = syscall(__NR_ioctl, r[1], 0xae41, 0);
> if (res != -1)
> r[2] = res;
> memcpy(
> (void*)0x2080,
>
> "\x01\x00\x00\x00\x00\x5b\x61\xbb\x96\x00\x00\x40\x00\x00\x00\x00\x01\x00"
>
> "\x08\x00\x00\x00\x00\x00\x0b\x77\xd1\x78\x4d\xd8\x3a\xed\xb1\x5c\x2e\x43"
>
> "\xaa\x43\x39\xd6\xff\xf5\xf0\xa8\x98\xf2\x3e\x37\x29\x89\xde\x88\xc6\x33"
>
> "\xfc\x2a\xdb\xb7\xe1\x4c\xac\x28\x61\x7b\x9c\xa9\xbc\x0d\xa0\x63\xfe\xfe"
>
> "\xe8\x75\xde\xdd\x19\x38\xdc\x34\xf5\xec\x05\xfd\xeb\x5d\xed\x2e\xaf\x22"
>
> "\xfa\xab\xb7\xe4\x42\x67\xd0\xaf\x06\x1c\x6a\x35\x67\x10\x55\xcb",
> 106);
> syscall(__NR_ioctl, r[2], 0x4008ae89, 0x2080);
> syscall(__NR_ioctl, r[2], 0xae80, 0);
> return 0;
> }
>
> This patch fixes it by bailing out scan ioapic if ioapic is not initialized
> in
> kernel.
>
> Reported-by: Wei Wu
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Wei Wu
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/x86.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 66d66d7..14b2bc4 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7455,7 +7455,8 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
> else {
> if (vcpu->arch.apicv_active)
> kvm_x86_ops->sync_pir_to_irr(vcpu);
> - kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
> + if (ioapic_in_kernel(vcpu->kvm))
> + kvm_ioapic_scan_entry(vcpu,
> vcpu->arch.ioapic_handled_vectors);
> }
>
> if (is_guest_mode(vcpu))
>
Queued, thanks.
Paolo
Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization
On 20/11/18 09:34, Wanpeng Li wrote:
> From: Wanpeng Li
>
> Reported by syzkaller:
>
> BUG: unable to handle kernel NULL pointer dereference at 01c8
> PGD 8003ec4da067 P4D 8003ec4da067 PUD 3f7bfa067 PMD 0
> Oops: [#1] PREEMPT SMP PTI
> CPU: 7 PID: 5059 Comm: debug Tainted: G OE 4.19.0-rc5 #16
> RIP: 0010:__lock_acquire+0x1a6/0x1990
> Call Trace:
> lock_acquire+0xdb/0x210
> _raw_spin_lock+0x38/0x70
> kvm_ioapic_scan_entry+0x3e/0x110 [kvm]
> vcpu_enter_guest+0x167e/0x1910 [kvm]
> kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
> kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
> do_vfs_ioctl+0xa5/0x690
> ksys_ioctl+0x6d/0x80
> __x64_sys_ioctl+0x1a/0x20
> do_syscall_64+0x83/0x6e0
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The reason is that the testcase writes hyperv synic HV_X64_MSR_SINT6 msr
> and triggers scan ioapic logic to load synic vectors into EOI exit bitmap.
> However, irqchip is not initialized by this simple testcase, ioapic/apic
> objects should not be accessed.
> This can be triggered by the following program:
>
> #define _GNU_SOURCE
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> uint64_t r[3] = {0x, 0x,
> 0x};
>
> int main(void)
> {
> syscall(__NR_mmap, 0x2000, 0x100, 3, 0x32, -1, 0);
> long res = 0;
> memcpy((void*)0x2040, "/dev/kvm", 9);
> res = syscall(__NR_openat, 0xff9c, 0x2040, 0, 0);
> if (res != -1)
> r[0] = res;
> res = syscall(__NR_ioctl, r[0], 0xae01, 0);
> if (res != -1)
> r[1] = res;
> res = syscall(__NR_ioctl, r[1], 0xae41, 0);
> if (res != -1)
> r[2] = res;
> memcpy(
> (void*)0x2080,
>
> "\x01\x00\x00\x00\x00\x5b\x61\xbb\x96\x00\x00\x40\x00\x00\x00\x00\x01\x00"
>
> "\x08\x00\x00\x00\x00\x00\x0b\x77\xd1\x78\x4d\xd8\x3a\xed\xb1\x5c\x2e\x43"
>
> "\xaa\x43\x39\xd6\xff\xf5\xf0\xa8\x98\xf2\x3e\x37\x29\x89\xde\x88\xc6\x33"
>
> "\xfc\x2a\xdb\xb7\xe1\x4c\xac\x28\x61\x7b\x9c\xa9\xbc\x0d\xa0\x63\xfe\xfe"
>
> "\xe8\x75\xde\xdd\x19\x38\xdc\x34\xf5\xec\x05\xfd\xeb\x5d\xed\x2e\xaf\x22"
>
> "\xfa\xab\xb7\xe4\x42\x67\xd0\xaf\x06\x1c\x6a\x35\x67\x10\x55\xcb",
> 106);
> syscall(__NR_ioctl, r[2], 0x4008ae89, 0x2080);
> syscall(__NR_ioctl, r[2], 0xae80, 0);
> return 0;
> }
>
> This patch fixes it by bailing out scan ioapic if ioapic is not initialized
> in
> kernel.
>
> Reported-by: Wei Wu
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Wei Wu
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/x86.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 66d66d7..14b2bc4 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7455,7 +7455,8 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
> else {
> if (vcpu->arch.apicv_active)
> kvm_x86_ops->sync_pir_to_irr(vcpu);
> - kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
> + if (ioapic_in_kernel(vcpu->kvm))
> + kvm_ioapic_scan_entry(vcpu,
> vcpu->arch.ioapic_handled_vectors);
> }
>
> if (is_guest_mode(vcpu))
>
Queued, thanks.
Paolo
Re: Question about "regulator: core: Only count load for enabled consumers" in -next
Hi,
On Sun, Nov 25, 2018 at 1:37 AM Brian Masney wrote:
> I bisected the issue to the following commit:
>
> 5451781dadf8 ("regulator: core: Only count load for enabled consumers")
>
> We have to increase the load for the sdhci in device tree in order for
> the phone to boot properly. This change was made with the commit:
>
> 03864e57770a ("ARM: dts: qcom: msm8974-hammerhead: increase load on l20
> for sdhci")
You have a 200 mA system load on this regulator? I guess this is a
workaround for drivers that don't set the load properly themselves?
I wonder if there is a bug in my patch where the system load doesn't
take effect if nobody ever calls set_load. Let's see... Does the
below fix things for you? It's totally untested and whitespace
damaged but I wanted to get a response out quick and I'm just walking
out the door. I'll test more / dig more either tonight or at work
tomorrow:
+++ b/drivers/regulator/core.c
@@ -1344,6 +1344,12 @@ static int set_machine_constraints(struct
regulator_dev *rdev,
rdev_err(rdev, "failed to set initial mode: %d\n", ret);
return ret;
}
+ } else if (rdev->constraints->system_load) {
+ /*
+* We'll only apply the initial system load if an
+* initial mode wasn't specified.
+*/
+ drms_uA_update(rdev);
}
Re: Question about "regulator: core: Only count load for enabled consumers" in -next
Hi,
On Sun, Nov 25, 2018 at 1:37 AM Brian Masney wrote:
> I bisected the issue to the following commit:
>
> 5451781dadf8 ("regulator: core: Only count load for enabled consumers")
>
> We have to increase the load for the sdhci in device tree in order for
> the phone to boot properly. This change was made with the commit:
>
> 03864e57770a ("ARM: dts: qcom: msm8974-hammerhead: increase load on l20
> for sdhci")
You have a 200 mA system load on this regulator? I guess this is a
workaround for drivers that don't set the load properly themselves?
I wonder if there is a bug in my patch where the system load doesn't
take effect if nobody ever calls set_load. Let's see... Does the
below fix things for you? It's totally untested and whitespace
damaged but I wanted to get a response out quick and I'm just walking
out the door. I'll test more / dig more either tonight or at work
tomorrow:
+++ b/drivers/regulator/core.c
@@ -1344,6 +1344,12 @@ static int set_machine_constraints(struct
regulator_dev *rdev,
rdev_err(rdev, "failed to set initial mode: %d\n", ret);
return ret;
}
+ } else if (rdev->constraints->system_load) {
+ /*
+* We'll only apply the initial system load if an
+* initial mode wasn't specified.
+*/
+ drms_uA_update(rdev);
}
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
* Aaro Koskinen [181125 16:58]: > Below changes get traffic going with DMA & g_ether... Oh cool, if you have dma and g_ether working, you should test it with a variable size ping test loop :) That should expose any issues within few minutes. Below is the test script I was using earlier, the tusb6010 comment there is probably no longer valid. Regards, Tony 8< #!/bin/bash # # At least tusb6010 dma needs 32-bit aligned buffers. # That can be done by setting no_skb_reserve with: # musb->g.quirk_avoids_skb_reserve = 1; # device=$1 size=$2 wraps=0 while [ 1 ]; do #echo "Pinging with size $size" if ! ping -w0 -c1 -s$size $device > /dev/null 2>&1; then break; fi size=$(expr $size + 1) if [ $size -gt 8192 ]; then wraps=$(expr $wraps + 1) echo "wrapping ($wraps) at $size" size=1 fi done echo "Test ran up to $size"
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
* Aaro Koskinen [181125 16:58]: > Below changes get traffic going with DMA & g_ether... Oh cool, if you have dma and g_ether working, you should test it with a variable size ping test loop :) That should expose any issues within few minutes. Below is the test script I was using earlier, the tusb6010 comment there is probably no longer valid. Regards, Tony 8< #!/bin/bash # # At least tusb6010 dma needs 32-bit aligned buffers. # That can be done by setting no_skb_reserve with: # musb->g.quirk_avoids_skb_reserve = 1; # device=$1 size=$2 wraps=0 while [ 1 ]; do #echo "Pinging with size $size" if ! ping -w0 -c1 -s$size $device > /dev/null 2>&1; then break; fi size=$(expr $size + 1) if [ $size -gt 8192 ]; then wraps=$(expr $wraps + 1) echo "wrapping ($wraps) at $size" size=1 fi done echo "Test ran up to $size"
[PATCH] staging: greybus: Parenthesis alignment
Some parameters are aligned with parentheses.
Some parentheses was opened at end of line.
Signed-off-by: Cristian Sicilia
---
Changes on v2:
* There was some function that was splitted in two line,
as suggested, is better to keep it in one line.
drivers/staging/greybus/audio_manager_module.c | 4 +-
drivers/staging/greybus/audio_manager_sysfs.c | 22 ++--
drivers/staging/greybus/audio_module.c | 20 ++--
drivers/staging/greybus/audio_topology.c | 63 ++--
drivers/staging/greybus/bootrom.c | 25 ++---
drivers/staging/greybus/camera.c | 12 +--
drivers/staging/greybus/connection.c | 82 +++
drivers/staging/greybus/control.c | 53 +-
drivers/staging/greybus/es2.c | 70 ++---
drivers/staging/greybus/gpio.c | 39 +++
drivers/staging/greybus/hid.c | 18 ++--
drivers/staging/greybus/i2c.c | 21 ++--
drivers/staging/greybus/module.c | 19 ++--
drivers/staging/greybus/operation.c| 135 +
drivers/staging/greybus/svc.c | 93 +
15 files changed, 343 insertions(+), 333 deletions(-)
diff --git a/drivers/staging/greybus/audio_manager_module.c
b/drivers/staging/greybus/audio_manager_module.c
index 52342e8..2bfd804 100644
--- a/drivers/staging/greybus/audio_manager_module.c
+++ b/drivers/staging/greybus/audio_manager_module.c
@@ -25,8 +25,8 @@ struct gb_audio_manager_module_attribute {
const char *buf, size_t count);
};
-static ssize_t gb_audio_module_attr_show(
- struct kobject *kobj, struct attribute *attr, char *buf)
+static ssize_t gb_audio_module_attr_show(struct kobject *kobj,
+struct attribute *attr, char *buf)
{
struct gb_audio_manager_module_attribute *attribute;
struct gb_audio_manager_module *module;
diff --git a/drivers/staging/greybus/audio_manager_sysfs.c
b/drivers/staging/greybus/audio_manager_sysfs.c
index 283fbed..ab882cc 100644
--- a/drivers/staging/greybus/audio_manager_sysfs.c
+++ b/drivers/staging/greybus/audio_manager_sysfs.c
@@ -11,9 +11,9 @@
#include "audio_manager.h"
#include "audio_manager_private.h"
-static ssize_t manager_sysfs_add_store(
- struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static ssize_t manager_sysfs_add_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
struct gb_audio_manager_module_descriptor desc = { {0} };
@@ -36,9 +36,9 @@ static ssize_t manager_sysfs_add_store(
static struct kobj_attribute manager_add_attribute =
__ATTR(add, 0664, NULL, manager_sysfs_add_store);
-static ssize_t manager_sysfs_remove_store(
- struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static ssize_t manager_sysfs_remove_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
int id;
@@ -57,9 +57,9 @@ static ssize_t manager_sysfs_remove_store(
static struct kobj_attribute manager_remove_attribute =
__ATTR(remove, 0664, NULL, manager_sysfs_remove_store);
-static ssize_t manager_sysfs_dump_store(
- struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static ssize_t manager_sysfs_dump_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
int id;
@@ -81,8 +81,8 @@ static ssize_t manager_sysfs_dump_store(
static struct kobj_attribute manager_dump_attribute =
__ATTR(dump, 0664, NULL, manager_sysfs_dump_store);
-static void manager_sysfs_init_attribute(
- struct kobject *kobj, struct kobj_attribute *kattr)
+static void manager_sysfs_init_attribute(struct kobject *kobj,
+struct kobj_attribute *kattr)
{
int err;
diff --git a/drivers/staging/greybus/audio_module.c
b/drivers/staging/greybus/audio_module.c
index d065334..300a2b4 100644
--- a/drivers/staging/greybus/audio_module.c
+++ b/drivers/staging/greybus/audio_module.c
@@ -18,7 +18,7 @@
*/
static int gbaudio_request_jack(struct gbaudio_module_info *module,
- struct gb_audio_jack_event_request *req)
+ struct gb_audio_jack_event_request *req)
{
int report;
struct snd_jack *jack = module->headset_jack.jack;
@@ -26,8 +26,8 @@ static int gbaudio_request_jack(struct gbaudio_module_info
*module,
if (!jack) {
dev_err_ratelimited(module->dev,
- "Invalid
[PATCH] staging: greybus: Parenthesis alignment
Some parameters are aligned with parentheses.
Some parentheses was opened at end of line.
Signed-off-by: Cristian Sicilia
---
Changes on v2:
* There was some function that was splitted in two line,
as suggested, is better to keep it in one line.
drivers/staging/greybus/audio_manager_module.c | 4 +-
drivers/staging/greybus/audio_manager_sysfs.c | 22 ++--
drivers/staging/greybus/audio_module.c | 20 ++--
drivers/staging/greybus/audio_topology.c | 63 ++--
drivers/staging/greybus/bootrom.c | 25 ++---
drivers/staging/greybus/camera.c | 12 +--
drivers/staging/greybus/connection.c | 82 +++
drivers/staging/greybus/control.c | 53 +-
drivers/staging/greybus/es2.c | 70 ++---
drivers/staging/greybus/gpio.c | 39 +++
drivers/staging/greybus/hid.c | 18 ++--
drivers/staging/greybus/i2c.c | 21 ++--
drivers/staging/greybus/module.c | 19 ++--
drivers/staging/greybus/operation.c| 135 +
drivers/staging/greybus/svc.c | 93 +
15 files changed, 343 insertions(+), 333 deletions(-)
diff --git a/drivers/staging/greybus/audio_manager_module.c
b/drivers/staging/greybus/audio_manager_module.c
index 52342e8..2bfd804 100644
--- a/drivers/staging/greybus/audio_manager_module.c
+++ b/drivers/staging/greybus/audio_manager_module.c
@@ -25,8 +25,8 @@ struct gb_audio_manager_module_attribute {
const char *buf, size_t count);
};
-static ssize_t gb_audio_module_attr_show(
- struct kobject *kobj, struct attribute *attr, char *buf)
+static ssize_t gb_audio_module_attr_show(struct kobject *kobj,
+struct attribute *attr, char *buf)
{
struct gb_audio_manager_module_attribute *attribute;
struct gb_audio_manager_module *module;
diff --git a/drivers/staging/greybus/audio_manager_sysfs.c
b/drivers/staging/greybus/audio_manager_sysfs.c
index 283fbed..ab882cc 100644
--- a/drivers/staging/greybus/audio_manager_sysfs.c
+++ b/drivers/staging/greybus/audio_manager_sysfs.c
@@ -11,9 +11,9 @@
#include "audio_manager.h"
#include "audio_manager_private.h"
-static ssize_t manager_sysfs_add_store(
- struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static ssize_t manager_sysfs_add_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
struct gb_audio_manager_module_descriptor desc = { {0} };
@@ -36,9 +36,9 @@ static ssize_t manager_sysfs_add_store(
static struct kobj_attribute manager_add_attribute =
__ATTR(add, 0664, NULL, manager_sysfs_add_store);
-static ssize_t manager_sysfs_remove_store(
- struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static ssize_t manager_sysfs_remove_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
int id;
@@ -57,9 +57,9 @@ static ssize_t manager_sysfs_remove_store(
static struct kobj_attribute manager_remove_attribute =
__ATTR(remove, 0664, NULL, manager_sysfs_remove_store);
-static ssize_t manager_sysfs_dump_store(
- struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static ssize_t manager_sysfs_dump_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
int id;
@@ -81,8 +81,8 @@ static ssize_t manager_sysfs_dump_store(
static struct kobj_attribute manager_dump_attribute =
__ATTR(dump, 0664, NULL, manager_sysfs_dump_store);
-static void manager_sysfs_init_attribute(
- struct kobject *kobj, struct kobj_attribute *kattr)
+static void manager_sysfs_init_attribute(struct kobject *kobj,
+struct kobj_attribute *kattr)
{
int err;
diff --git a/drivers/staging/greybus/audio_module.c
b/drivers/staging/greybus/audio_module.c
index d065334..300a2b4 100644
--- a/drivers/staging/greybus/audio_module.c
+++ b/drivers/staging/greybus/audio_module.c
@@ -18,7 +18,7 @@
*/
static int gbaudio_request_jack(struct gbaudio_module_info *module,
- struct gb_audio_jack_event_request *req)
+ struct gb_audio_jack_event_request *req)
{
int report;
struct snd_jack *jack = module->headset_jack.jack;
@@ -26,8 +26,8 @@ static int gbaudio_request_jack(struct gbaudio_module_info
*module,
if (!jack) {
dev_err_ratelimited(module->dev,
- "Invalid
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
Hi,
On Sun, Nov 25, 2018 at 11:11:05AM +, Russell King - ARM Linux wrote:
> I think we're better off leaving omap-udc well alone, and if it's
> now broken with DMA, then that's unfortunate - it would require
> someone with the hardware to diagnose the problem and fix it. I
> think trying to convert it to dmaengine would be risking way more
> problems than its worth.
Well, there's also an option to use dmaengine only for 16xx at the
beginning.
My current guess is that 15xx DMA has been broken at least since
65111084c63d ("USB: more omap_udc updates (dma and omap1710)").
There are two changes in that patch that broke it:
"use 16 bit DMA access" ==> CPC off-by-one becomes now off-by-two...?
"allow burst/pack for memory access" ==> no idea why
Below changes get traffic going with DMA & g_ether...
A.
diff --git a/drivers/usb/gadget/udc/omap_udc.c
b/drivers/usb/gadget/udc/omap_udc.c
index fcf13ef33b31..8094a0380057 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -498,7 +498,7 @@ static u16 dma_dest_len(struct omap_ep *ep, dma_addr_t
start)
end |= start & (0x << 16);
if (cpu_is_omap15xx())
- end++;
+ end += 2;
if (end < start)
end += 0x1;
return end - start;
@@ -730,10 +730,12 @@ static void dma_channel_claim(struct omap_ep *ep,
unsigned channel)
ep->ep.name, dma_error, ep, >lch);
if (status == 0) {
omap_writew(reg, UDC_TXDMA_CFG);
- /* EMIFF or SDRC */
- omap_set_dma_src_burst_mode(ep->lch,
- OMAP_DMA_DATA_BURST_4);
- omap_set_dma_src_data_pack(ep->lch, 1);
+ if (!cpu_is_omap15xx()) {
+ /* EMIFF or SDRC */
+ omap_set_dma_src_burst_mode(ep->lch,
+ OMAP_DMA_DATA_BURST_4);
+ omap_set_dma_src_data_pack(ep->lch, 1);
+ }
/* TIPB */
omap_set_dma_dest_params(ep->lch,
OMAP_DMA_PORT_TIPB,
@@ -753,10 +755,12 @@ static void dma_channel_claim(struct omap_ep *ep,
unsigned channel)
OMAP_DMA_AMODE_CONSTANT,
UDC_DATA_DMA,
0, 0);
- /* EMIFF or SDRC */
- omap_set_dma_dest_burst_mode(ep->lch,
- OMAP_DMA_DATA_BURST_4);
- omap_set_dma_dest_data_pack(ep->lch, 1);
+ if (!cpu_is_omap15xx()) {
+ /* EMIFF or SDRC */
+ omap_set_dma_dest_burst_mode(ep->lch,
+ OMAP_DMA_DATA_BURST_4);
+ omap_set_dma_dest_data_pack(ep->lch, 1);
+ }
}
}
if (status)
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
Hi,
On Sun, Nov 25, 2018 at 11:11:05AM +, Russell King - ARM Linux wrote:
> I think we're better off leaving omap-udc well alone, and if it's
> now broken with DMA, then that's unfortunate - it would require
> someone with the hardware to diagnose the problem and fix it. I
> think trying to convert it to dmaengine would be risking way more
> problems than its worth.
Well, there's also an option to use dmaengine only for 16xx at the
beginning.
My current guess is that 15xx DMA has been broken at least since
65111084c63d ("USB: more omap_udc updates (dma and omap1710)").
There are two changes in that patch that broke it:
"use 16 bit DMA access" ==> CPC off-by-one becomes now off-by-two...?
"allow burst/pack for memory access" ==> no idea why
Below changes get traffic going with DMA & g_ether...
A.
diff --git a/drivers/usb/gadget/udc/omap_udc.c
b/drivers/usb/gadget/udc/omap_udc.c
index fcf13ef33b31..8094a0380057 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -498,7 +498,7 @@ static u16 dma_dest_len(struct omap_ep *ep, dma_addr_t
start)
end |= start & (0x << 16);
if (cpu_is_omap15xx())
- end++;
+ end += 2;
if (end < start)
end += 0x1;
return end - start;
@@ -730,10 +730,12 @@ static void dma_channel_claim(struct omap_ep *ep,
unsigned channel)
ep->ep.name, dma_error, ep, >lch);
if (status == 0) {
omap_writew(reg, UDC_TXDMA_CFG);
- /* EMIFF or SDRC */
- omap_set_dma_src_burst_mode(ep->lch,
- OMAP_DMA_DATA_BURST_4);
- omap_set_dma_src_data_pack(ep->lch, 1);
+ if (!cpu_is_omap15xx()) {
+ /* EMIFF or SDRC */
+ omap_set_dma_src_burst_mode(ep->lch,
+ OMAP_DMA_DATA_BURST_4);
+ omap_set_dma_src_data_pack(ep->lch, 1);
+ }
/* TIPB */
omap_set_dma_dest_params(ep->lch,
OMAP_DMA_PORT_TIPB,
@@ -753,10 +755,12 @@ static void dma_channel_claim(struct omap_ep *ep,
unsigned channel)
OMAP_DMA_AMODE_CONSTANT,
UDC_DATA_DMA,
0, 0);
- /* EMIFF or SDRC */
- omap_set_dma_dest_burst_mode(ep->lch,
- OMAP_DMA_DATA_BURST_4);
- omap_set_dma_dest_data_pack(ep->lch, 1);
+ if (!cpu_is_omap15xx()) {
+ /* EMIFF or SDRC */
+ omap_set_dma_dest_burst_mode(ep->lch,
+ OMAP_DMA_DATA_BURST_4);
+ omap_set_dma_dest_data_pack(ep->lch, 1);
+ }
}
}
if (status)
[PATCH] MAINTAINERS: change Sparse's maintainer
I'm taking over the maintainance of Sparse so add myself as maintainer and move Christopher's info to CREDITS. Signed-off-by: Luc Van Oostenryck --- CREDITS | 4 MAINTAINERS | 3 +-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/CREDITS b/CREDITS index 5befd2d71..3d3e79cef 100644 --- a/CREDITS +++ b/CREDITS @@ -2200,6 +2200,10 @@ S: Post Office Box 371 S: North Little Rock, Arkansas 72115 S: USA +N: Christopher Li +E: spa...@chrisli.org +D: Sparse maintainer 2009 - 2018 + N: Stephan Linz E: l...@mazet.de E: stephan.l...@gmx.de diff --git a/MAINTAINERS b/MAINTAINERS index 0abecc528..68c7435f2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13977,11 +13977,10 @@ F:drivers/tty/serial/sunzilog.h F: drivers/tty/vcc.c SPARSE CHECKER -M: "Christopher Li" +M: "Luc Van Oostenryck" L: linux-spa...@vger.kernel.org W: https://sparse.wiki.kernel.org/ T: git git://git.kernel.org/pub/scm/devel/sparse/sparse.git -T: git git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git S: Maintained F: include/linux/compiler.h -- 2.19.0
[PATCH] MAINTAINERS: change Sparse's maintainer
I'm taking over the maintainance of Sparse so add myself as maintainer and move Christopher's info to CREDITS. Signed-off-by: Luc Van Oostenryck --- CREDITS | 4 MAINTAINERS | 3 +-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/CREDITS b/CREDITS index 5befd2d71..3d3e79cef 100644 --- a/CREDITS +++ b/CREDITS @@ -2200,6 +2200,10 @@ S: Post Office Box 371 S: North Little Rock, Arkansas 72115 S: USA +N: Christopher Li +E: spa...@chrisli.org +D: Sparse maintainer 2009 - 2018 + N: Stephan Linz E: l...@mazet.de E: stephan.l...@gmx.de diff --git a/MAINTAINERS b/MAINTAINERS index 0abecc528..68c7435f2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13977,11 +13977,10 @@ F:drivers/tty/serial/sunzilog.h F: drivers/tty/vcc.c SPARSE CHECKER -M: "Christopher Li" +M: "Luc Van Oostenryck" L: linux-spa...@vger.kernel.org W: https://sparse.wiki.kernel.org/ T: git git://git.kernel.org/pub/scm/devel/sparse/sparse.git -T: git git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git S: Maintained F: include/linux/compiler.h -- 2.19.0
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
>> On Nov 25, 2018, at 6:53 AM, Jarkko Sakkinen >> wrote: >> >> On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: >> On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: At a high level, addressing these issues is straight forward. First, the driver needs to support authorization equivalent to that which is implemented in the current Intel Launch Enclave, ie. control over the SGX_FLAGS_PROVISION_KEY attribute. >>> >>> I agree, hence my email :) >> >> Started to scratch my head that is it really an issue that any enclave >> can provision in the end? >> >> Direct quote from your first response: >> >> "In particular, the ability to run enclaves with the provisioning bit set >> is somewhat sensitive, since it effectively allows access to a stable >> fingerprint of the system." >> >> As can be seen from the key derivation table this does not exactly hold >> so you should refine your original argument before we can consider any >> type of change. >> >> I just don't see what it is so wrong for any enclave to be able to tell >> that it really is an enclave. > > I mean I can understand why Greg wants LE although I don't understand > what benefit does it bring to anyone to lock in for enclave to allow > to identify itself. > > What you are proposing does not really bring any additional security if > we consider a threat model where the kernel is an adversary but it makes > the software stack more clanky to use. Agreed. What I’m proposing adds additional security if the kernel is *not* compromised. There are other ways to accomplish it that might be better in some respects. For example, there could be /dev/sgx and /dev/sgx_rights/provision. The former exposes the whole sgx API, except that it doesn’t allow provisioning by default. The latter does nothing by itself. To run a provisioning enclave, you open both nodes, then do something like: ioctl(sgx, SGX_IOC_ADD_RIGHT, sgx_provisioning); This requires extra syscalls, but it doesn’t have the combinatorial explosion problem.
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
>> On Nov 25, 2018, at 6:53 AM, Jarkko Sakkinen >> wrote: >> >> On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: >> On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: At a high level, addressing these issues is straight forward. First, the driver needs to support authorization equivalent to that which is implemented in the current Intel Launch Enclave, ie. control over the SGX_FLAGS_PROVISION_KEY attribute. >>> >>> I agree, hence my email :) >> >> Started to scratch my head that is it really an issue that any enclave >> can provision in the end? >> >> Direct quote from your first response: >> >> "In particular, the ability to run enclaves with the provisioning bit set >> is somewhat sensitive, since it effectively allows access to a stable >> fingerprint of the system." >> >> As can be seen from the key derivation table this does not exactly hold >> so you should refine your original argument before we can consider any >> type of change. >> >> I just don't see what it is so wrong for any enclave to be able to tell >> that it really is an enclave. > > I mean I can understand why Greg wants LE although I don't understand > what benefit does it bring to anyone to lock in for enclave to allow > to identify itself. > > What you are proposing does not really bring any additional security if > we consider a threat model where the kernel is an adversary but it makes > the software stack more clanky to use. Agreed. What I’m proposing adds additional security if the kernel is *not* compromised. There are other ways to accomplish it that might be better in some respects. For example, there could be /dev/sgx and /dev/sgx_rights/provision. The former exposes the whole sgx API, except that it doesn’t allow provisioning by default. The latter does nothing by itself. To run a provisioning enclave, you open both nodes, then do something like: ioctl(sgx, SGX_IOC_ADD_RIGHT, sgx_provisioning); This requires extra syscalls, but it doesn’t have the combinatorial explosion problem.
The "udl" driver crashes the kernel.
When I connect my Displaylink DL-165 adapter to my Debian/testing machine, the "udl" driver is loaded and the following error messages appears in kernel logs: Nov 7 20:47:30 wzdell kernel: [ 205.871354] usb 4-1.2: new high-speed USB device number 4 using ehci-pci Nov 7 20:47:35 wzdell kernel: [ 211.209020] usb 4-1.2: New USB device found, idVendor=17e9, idProduct=0290, bcdDevice= 0.01 Nov 7 20:47:35 wzdell kernel: [ 211.209027] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 7 20:47:35 wzdell kernel: [ 211.209032] usb 4-1.2: Product: DL-165 Adapter Nov 7 20:47:35 wzdell kernel: [ 211.209036] usb 4-1.2: Manufacturer: DisplayLink Nov 7 20:47:35 wzdell kernel: [ 211.209040] usb 4-1.2: SerialNumber: 102140 Nov 7 20:47:35 wzdell mtp-probe: checking bus 4, device 4: "/sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.2" Nov 7 20:47:35 wzdell mtp-probe: bus: 4, device: 4 was not an MTP device Nov 7 20:47:35 wzdell kernel: [ 211.269753] [drm] vendor descriptor length:22 data:22 5f 01 00 20 05 00 01 03 04 02 Nov 7 20:47:35 wzdell kernel: [ 211.320940] [drm] Cannot find any crtc or sizes Nov 7 20:47:35 wzdell kernel: [ 211.320962] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Nov 7 20:47:35 wzdell kernel: [ 211.320963] [drm] No driver support for vblank timestamp query. Nov 7 20:47:35 wzdell kernel: [ 211.320999] [drm] Initialized udl 0.0.1 20120220 for 4-1.2:1.0 on minor 1 Nov 7 20:47:35 wzdell kernel: [ 211.321002] [drm] Initialized udl on minor 1 Nov 7 20:47:35 wzdell kernel: [ 211.321078] usbcore: registered new interface driver udl Nov 7 20:47:37 wzdell kernel: [ 212.700722] WARNING: CPU: 0 PID: 1024 at /build/linux-iActNR/linux-4.18.10/drivers/gpu/drm/drm_gem.c:893 drm_gem_object_put+0x34/0x40 [drm] Nov 7 20:47:37 wzdell kernel: [ 212.700726] Modules linked in: udl rfcomm ctr ccm cpufreq_userspace cpufreq_conservative cpufreq_powersave bnep bbswitch(O) nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nft_counter xt_owner xt_state xt_conntrack nf_conntrack libcrc32c nft_compat nf_tables nfnetlink binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass uvcvideo arc4 iwldvm videobuf2_vmalloc mac80211 videobuf2_memops videobuf2_v4l2 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel videobuf2_common snd_hda_codec videodev snd_hda_core snd_hwdep snd_pcm snd_timer media snd soundcore i915 btusb btrtl btbcm btintel bluetooth iwlwifi dell_laptop dell_wmi dell_smbios mei_me drbg ansi_cprng mei ecdh_generic wmi_bmof dcdbas cfg80211 drm_kms_helper sparse_keymap dell_wmi_descriptor Nov 7 20:47:37 wzdell kernel: [ 212.700822] intel_cstate drm intel_uncore intel_rapl_perf dell_smm_hwmon evdev iTCO_wdt iTCO_vendor_support joydev rfkill video serio_raw i2c_algo_bit pcspkr sg pcc_cpufreq wmi dell_smo8800 button battery ac parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb algif_skcipher af_alg dm_crypt dm_mod sr_mod cdrom sd_mod ums_realtek uas usb_storage crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel xhci_pci aes_x86_64 ehci_pci crypto_simd libata xhci_hcd ehci_hcd cryptd glue_helper psmouse scsi_mod i2c_i801 r8169 lpc_ich mii usbcore usb_common thermal Nov 7 20:47:37 wzdell kernel: [ 212.700925] CPU: 0 PID: 1024 Comm: Xorg Tainted: G O 4.18.0-2-amd64 #1 Debian 4.18.10-2 Nov 7 20:47:37 wzdell kernel: [ 212.700927] Hardware name: Dell Inc. Dell System Vostro 3750/0VP036, BIOS A14 09/26/2012 Nov 7 20:47:37 wzdell kernel: [ 212.700955] RIP: 0010:drm_gem_object_put+0x34/0x40 [drm] Nov 7 20:47:37 wzdell kernel: [ 212.700957] Code: 53 48 8b 47 08 48 8b 40 68 48 a9 f8 ff ff ff 74 19 48 89 fb e8 7d c3 02 de 84 c0 75 02 5b c3 48 89 df 5b e9 ee fc ff ff f3 c3 <0f> 0b eb e3 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 42 08 48 Nov 7 20:47:37 wzdell kernel: [ 212.701035] RSP: 0018:ac86826bbd00 EFLAGS: 00010246 Nov 7 20:47:37 wzdell kernel: [ 212.701039] RAX: RBX: 95fc65313800 RCX: Nov 7 20:47:37 wzdell kernel: [ 212.701042] RDX: RSI: 95fc662b0610 RDI: 95fc65313800 Nov 7 20:47:37 wzdell kernel: [ 212.701045] RBP: 95fc31f1a020 R08: 95fc662b0610 R09: 95fc662b06c0 Nov 7 20:47:37 wzdell kernel: [ 212.701047] R10: 0010 R11: 0040 R12: Nov 7 20:47:37 wzdell kernel: [ 212.701050] R13: ac86826bbdc8 R14: ac86826bbdc0 R15: 00b3 Nov 7 20:47:37 wzdell kernel: [ 212.701054] FS: 7f78c0ceba80() GS:95fc7e40() knlGS: Nov 7 20:47:37 wzdell kernel: [ 212.701057] CS: 0010 DS: ES: CR0: 80050033 Nov 7 20:47:37 wzdell kernel: [ 212.701060] CR2: 7f78abdfac94 CR3: 0004287fe002 CR4: 000606f0 Nov 7 20:47:37 wzdell kernel: [ 212.701063] Call Trace: Nov 7 20:47:37 wzdell
The "udl" driver crashes the kernel.
When I connect my Displaylink DL-165 adapter to my Debian/testing machine, the "udl" driver is loaded and the following error messages appears in kernel logs: Nov 7 20:47:30 wzdell kernel: [ 205.871354] usb 4-1.2: new high-speed USB device number 4 using ehci-pci Nov 7 20:47:35 wzdell kernel: [ 211.209020] usb 4-1.2: New USB device found, idVendor=17e9, idProduct=0290, bcdDevice= 0.01 Nov 7 20:47:35 wzdell kernel: [ 211.209027] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 7 20:47:35 wzdell kernel: [ 211.209032] usb 4-1.2: Product: DL-165 Adapter Nov 7 20:47:35 wzdell kernel: [ 211.209036] usb 4-1.2: Manufacturer: DisplayLink Nov 7 20:47:35 wzdell kernel: [ 211.209040] usb 4-1.2: SerialNumber: 102140 Nov 7 20:47:35 wzdell mtp-probe: checking bus 4, device 4: "/sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.2" Nov 7 20:47:35 wzdell mtp-probe: bus: 4, device: 4 was not an MTP device Nov 7 20:47:35 wzdell kernel: [ 211.269753] [drm] vendor descriptor length:22 data:22 5f 01 00 20 05 00 01 03 04 02 Nov 7 20:47:35 wzdell kernel: [ 211.320940] [drm] Cannot find any crtc or sizes Nov 7 20:47:35 wzdell kernel: [ 211.320962] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Nov 7 20:47:35 wzdell kernel: [ 211.320963] [drm] No driver support for vblank timestamp query. Nov 7 20:47:35 wzdell kernel: [ 211.320999] [drm] Initialized udl 0.0.1 20120220 for 4-1.2:1.0 on minor 1 Nov 7 20:47:35 wzdell kernel: [ 211.321002] [drm] Initialized udl on minor 1 Nov 7 20:47:35 wzdell kernel: [ 211.321078] usbcore: registered new interface driver udl Nov 7 20:47:37 wzdell kernel: [ 212.700722] WARNING: CPU: 0 PID: 1024 at /build/linux-iActNR/linux-4.18.10/drivers/gpu/drm/drm_gem.c:893 drm_gem_object_put+0x34/0x40 [drm] Nov 7 20:47:37 wzdell kernel: [ 212.700726] Modules linked in: udl rfcomm ctr ccm cpufreq_userspace cpufreq_conservative cpufreq_powersave bnep bbswitch(O) nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nft_counter xt_owner xt_state xt_conntrack nf_conntrack libcrc32c nft_compat nf_tables nfnetlink binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass uvcvideo arc4 iwldvm videobuf2_vmalloc mac80211 videobuf2_memops videobuf2_v4l2 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel videobuf2_common snd_hda_codec videodev snd_hda_core snd_hwdep snd_pcm snd_timer media snd soundcore i915 btusb btrtl btbcm btintel bluetooth iwlwifi dell_laptop dell_wmi dell_smbios mei_me drbg ansi_cprng mei ecdh_generic wmi_bmof dcdbas cfg80211 drm_kms_helper sparse_keymap dell_wmi_descriptor Nov 7 20:47:37 wzdell kernel: [ 212.700822] intel_cstate drm intel_uncore intel_rapl_perf dell_smm_hwmon evdev iTCO_wdt iTCO_vendor_support joydev rfkill video serio_raw i2c_algo_bit pcspkr sg pcc_cpufreq wmi dell_smo8800 button battery ac parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb algif_skcipher af_alg dm_crypt dm_mod sr_mod cdrom sd_mod ums_realtek uas usb_storage crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel xhci_pci aes_x86_64 ehci_pci crypto_simd libata xhci_hcd ehci_hcd cryptd glue_helper psmouse scsi_mod i2c_i801 r8169 lpc_ich mii usbcore usb_common thermal Nov 7 20:47:37 wzdell kernel: [ 212.700925] CPU: 0 PID: 1024 Comm: Xorg Tainted: G O 4.18.0-2-amd64 #1 Debian 4.18.10-2 Nov 7 20:47:37 wzdell kernel: [ 212.700927] Hardware name: Dell Inc. Dell System Vostro 3750/0VP036, BIOS A14 09/26/2012 Nov 7 20:47:37 wzdell kernel: [ 212.700955] RIP: 0010:drm_gem_object_put+0x34/0x40 [drm] Nov 7 20:47:37 wzdell kernel: [ 212.700957] Code: 53 48 8b 47 08 48 8b 40 68 48 a9 f8 ff ff ff 74 19 48 89 fb e8 7d c3 02 de 84 c0 75 02 5b c3 48 89 df 5b e9 ee fc ff ff f3 c3 <0f> 0b eb e3 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 42 08 48 Nov 7 20:47:37 wzdell kernel: [ 212.701035] RSP: 0018:ac86826bbd00 EFLAGS: 00010246 Nov 7 20:47:37 wzdell kernel: [ 212.701039] RAX: RBX: 95fc65313800 RCX: Nov 7 20:47:37 wzdell kernel: [ 212.701042] RDX: RSI: 95fc662b0610 RDI: 95fc65313800 Nov 7 20:47:37 wzdell kernel: [ 212.701045] RBP: 95fc31f1a020 R08: 95fc662b0610 R09: 95fc662b06c0 Nov 7 20:47:37 wzdell kernel: [ 212.701047] R10: 0010 R11: 0040 R12: Nov 7 20:47:37 wzdell kernel: [ 212.701050] R13: ac86826bbdc8 R14: ac86826bbdc0 R15: 00b3 Nov 7 20:47:37 wzdell kernel: [ 212.701054] FS: 7f78c0ceba80() GS:95fc7e40() knlGS: Nov 7 20:47:37 wzdell kernel: [ 212.701057] CS: 0010 DS: ES: CR0: 80050033 Nov 7 20:47:37 wzdell kernel: [ 212.701060] CR2: 7f78abdfac94 CR3: 0004287fe002 CR4: 000606f0 Nov 7 20:47:37 wzdell kernel: [ 212.701063] Call Trace: Nov 7 20:47:37 wzdell
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 06:14:44AM -0800, Matt Ranostay wrote:
> On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
> wrote:
> >
> > On Sun, 25 Nov 2018 05:51:32 -0800
> > Matt Ranostay wrote:
> >
> > > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski
> > > wrote:
> > > >
> > > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > > is de facto standard. Existing air quality sensors usually follow
> > > > this convention and are capable of returning measurements using
> > > > this unit.
> > > >
> > > > IIO currently does not offer suitable channel type for this
> > > > type of measurements hence this patch adds this.
> > > >
> > > > In addition, two modifiers are introduced used for distinguishing
> > > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > > >
> > > > Signed-off-by: Tomasz Duszynski
> > > > ---
> > > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > > drivers/iio/industrialio-core.c | 3 +++
> > > > include/uapi/linux/iio/types.h | 3 +++
> > > > tools/iio/iio_event_monitor.c | 6 ++
> > > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > > index 8127a08e366d..ce0ed140660d 100644
> > > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > > Contact: linux-...@vger.kernel.org
> > > > Description:
> > > > Raw (unscaled) phase difference reading from channel Y
> > > > - that can be processed to radians.
> > > > \ No newline at end of file
> > > > + that can be processed to radians.
> > > > +
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > > +KernelVersion: 4.21
> > > > +Contact: linux-...@vger.kernel.org
> > > > +Description:
> > > > + Mass concentration reading of particulate matter in ug
> > > > / m3.
> > > > diff --git a/drivers/iio/industrialio-core.c
> > > > b/drivers/iio/industrialio-core.c
> > > > index a062cfddc5af..2a9ef600c1fb 100644
> > > > --- a/drivers/iio/industrialio-core.c
> > > > +++ b/drivers/iio/industrialio-core.c
> > > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] =
> > > > {
> > > > [IIO_GRAVITY] = "gravity",
> > > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > > [IIO_PHASE] = "phase",
> > > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > > };
> > > >
> > > > static const char * const iio_modifier_names[] = {
> > > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > > [IIO_MOD_Q] = "q",
> > > > [IIO_MOD_CO2] = "co2",
> > > > [IIO_MOD_VOC] = "voc",
> > > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > > + [IIO_MOD_PM10] = "pm10",
> > > > };
> > > >
> > > > /* relies on pairs of these shared then separate */
> > > > diff --git a/include/uapi/linux/iio/types.h
> > > > b/include/uapi/linux/iio/types.h
> > > > index 92baabc103ac..465044b42af5 100644
> > > > --- a/include/uapi/linux/iio/types.h
> > > > +++ b/include/uapi/linux/iio/types.h
> > > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > > IIO_GRAVITY,
> > > > IIO_POSITIONRELATIVE,
> > > > IIO_PHASE,
> > > > + IIO_MASSCONCENTRATION,
> > >
> > > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > > per cubic meter?
> >
> > Currently concentration is defined as a percentage reading of a substance
> > (which does make me wonder if it is meant to be percentage of the volume or
> > percentage of the mass?) Either way, if can't convert to a density
> > measurement
> > as it's a unit free ratio (I think).
>
> Seems like it can be both.. guessing all the atmosphere ( CO2, VOC,
> etc) ones are mass/density because on how they work.
Hmm, but still percentage was picked up for IIO_CONCENTRATION which does
really match PM expectations. Perhaps if units were sticked to modifiers
it whould be easier to reuse that.
> But the electro-conductivity sensor that is using IIO_CONCENTRATION
> channels is likely from percentage of volume.
>
> - Matt
>
> >
> > >
> > > > };
> > > >
> > > > enum iio_modifier {
> > > > @@ -87,6 +88,8 @@ enum iio_modifier {
> > > > IIO_MOD_VOC,
> > > > IIO_MOD_LIGHT_UV,
> > > > IIO_MOD_LIGHT_DUV,
> > > > + IIO_MOD_PM2p5,
> > >
> > > I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> > > a bit
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 06:14:44AM -0800, Matt Ranostay wrote:
> On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
> wrote:
> >
> > On Sun, 25 Nov 2018 05:51:32 -0800
> > Matt Ranostay wrote:
> >
> > > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski
> > > wrote:
> > > >
> > > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > > is de facto standard. Existing air quality sensors usually follow
> > > > this convention and are capable of returning measurements using
> > > > this unit.
> > > >
> > > > IIO currently does not offer suitable channel type for this
> > > > type of measurements hence this patch adds this.
> > > >
> > > > In addition, two modifiers are introduced used for distinguishing
> > > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > > >
> > > > Signed-off-by: Tomasz Duszynski
> > > > ---
> > > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > > drivers/iio/industrialio-core.c | 3 +++
> > > > include/uapi/linux/iio/types.h | 3 +++
> > > > tools/iio/iio_event_monitor.c | 6 ++
> > > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > > index 8127a08e366d..ce0ed140660d 100644
> > > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > > Contact: linux-...@vger.kernel.org
> > > > Description:
> > > > Raw (unscaled) phase difference reading from channel Y
> > > > - that can be processed to radians.
> > > > \ No newline at end of file
> > > > + that can be processed to radians.
> > > > +
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > > +KernelVersion: 4.21
> > > > +Contact: linux-...@vger.kernel.org
> > > > +Description:
> > > > + Mass concentration reading of particulate matter in ug
> > > > / m3.
> > > > diff --git a/drivers/iio/industrialio-core.c
> > > > b/drivers/iio/industrialio-core.c
> > > > index a062cfddc5af..2a9ef600c1fb 100644
> > > > --- a/drivers/iio/industrialio-core.c
> > > > +++ b/drivers/iio/industrialio-core.c
> > > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] =
> > > > {
> > > > [IIO_GRAVITY] = "gravity",
> > > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > > [IIO_PHASE] = "phase",
> > > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > > };
> > > >
> > > > static const char * const iio_modifier_names[] = {
> > > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > > [IIO_MOD_Q] = "q",
> > > > [IIO_MOD_CO2] = "co2",
> > > > [IIO_MOD_VOC] = "voc",
> > > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > > + [IIO_MOD_PM10] = "pm10",
> > > > };
> > > >
> > > > /* relies on pairs of these shared then separate */
> > > > diff --git a/include/uapi/linux/iio/types.h
> > > > b/include/uapi/linux/iio/types.h
> > > > index 92baabc103ac..465044b42af5 100644
> > > > --- a/include/uapi/linux/iio/types.h
> > > > +++ b/include/uapi/linux/iio/types.h
> > > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > > IIO_GRAVITY,
> > > > IIO_POSITIONRELATIVE,
> > > > IIO_PHASE,
> > > > + IIO_MASSCONCENTRATION,
> > >
> > > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > > per cubic meter?
> >
> > Currently concentration is defined as a percentage reading of a substance
> > (which does make me wonder if it is meant to be percentage of the volume or
> > percentage of the mass?) Either way, if can't convert to a density
> > measurement
> > as it's a unit free ratio (I think).
>
> Seems like it can be both.. guessing all the atmosphere ( CO2, VOC,
> etc) ones are mass/density because on how they work.
Hmm, but still percentage was picked up for IIO_CONCENTRATION which does
really match PM expectations. Perhaps if units were sticked to modifiers
it whould be easier to reuse that.
> But the electro-conductivity sensor that is using IIO_CONCENTRATION
> channels is likely from percentage of volume.
>
> - Matt
>
> >
> > >
> > > > };
> > > >
> > > > enum iio_modifier {
> > > > @@ -87,6 +88,8 @@ enum iio_modifier {
> > > > IIO_MOD_VOC,
> > > > IIO_MOD_LIGHT_UV,
> > > > IIO_MOD_LIGHT_DUV,
> > > > + IIO_MOD_PM2p5,
> > >
> > > I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> > > a bit
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 02:03:16PM +, Jonathan Cameron wrote:
> On Sun, 25 Nov 2018 05:51:32 -0800
> Matt Ranostay wrote:
>
> > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> > >
> > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > is de facto standard. Existing air quality sensors usually follow
> > > this convention and are capable of returning measurements using
> > > this unit.
> > >
> > > IIO currently does not offer suitable channel type for this
> > > type of measurements hence this patch adds this.
> > >
> > > In addition, two modifiers are introduced used for distinguishing
> > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > >
> > > Signed-off-by: Tomasz Duszynski
> > > ---
> > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > drivers/iio/industrialio-core.c | 3 +++
> > > include/uapi/linux/iio/types.h | 3 +++
> > > tools/iio/iio_event_monitor.c | 6 ++
> > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > index 8127a08e366d..ce0ed140660d 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > Contact: linux-...@vger.kernel.org
> > > Description:
> > > Raw (unscaled) phase difference reading from channel Y
> > > - that can be processed to radians.
> > > \ No newline at end of file
> > > + that can be processed to radians.
> > > +
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > +KernelVersion: 4.21
> > > +Contact: linux-...@vger.kernel.org
> > > +Description:
> > > + Mass concentration reading of particulate matter in ug /
> > > m3.
> > > diff --git a/drivers/iio/industrialio-core.c
> > > b/drivers/iio/industrialio-core.c
> > > index a062cfddc5af..2a9ef600c1fb 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > > [IIO_GRAVITY] = "gravity",
> > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > [IIO_PHASE] = "phase",
> > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > };
> > >
> > > static const char * const iio_modifier_names[] = {
> > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > [IIO_MOD_Q] = "q",
> > > [IIO_MOD_CO2] = "co2",
> > > [IIO_MOD_VOC] = "voc",
> > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > + [IIO_MOD_PM10] = "pm10",
> > > };
> > >
> > > /* relies on pairs of these shared then separate */
> > > diff --git a/include/uapi/linux/iio/types.h
> > > b/include/uapi/linux/iio/types.h
> > > index 92baabc103ac..465044b42af5 100644
> > > --- a/include/uapi/linux/iio/types.h
> > > +++ b/include/uapi/linux/iio/types.h
> > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > IIO_GRAVITY,
> > > IIO_POSITIONRELATIVE,
> > > IIO_PHASE,
> > > + IIO_MASSCONCENTRATION,
> >
> > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > per cubic meter?
>
> Currently concentration is defined as a percentage reading of a substance
> (which does make me wonder if it is meant to be percentage of the volume or
> percentage of the mass?) Either way, if can't convert to a density
> measurement
> as it's a unit free ratio (I think).
>
And this is the main reason behind introducing a new channel type.
> >
> > > };
> > >
> > > enum iio_modifier {
> > > @@ -87,6 +88,8 @@ enum iio_modifier {
> > > IIO_MOD_VOC,
> > > IIO_MOD_LIGHT_UV,
> > > IIO_MOD_LIGHT_DUV,
> > > + IIO_MOD_PM2p5,
> >
> > I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> > a bit non-standard for iio defines/enum.
> It is a bit odd and will get us scripted reports so maybe best to
> just go upper case and not worry about it.
>
Initially I came up with IIO_MOD_PM2_5 but eventually replaced
underscore with 'p' meaning 'decimal point'. Anyway, I am okay with the
suggested change.
> Jonathan
> >
> > - Matt
> >
> > > + IIO_MOD_PM10,
> > > };
> > >
> > > enum iio_event_type {
> > > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > > index ac2de6b7e89f..f0fcfeddba2b 100644
> > > --- a/tools/iio/iio_event_monitor.c
> > > +++ b/tools/iio/iio_event_monitor.c
> > > @@ -60,6 +60,7 @@ static const char *
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 02:03:16PM +, Jonathan Cameron wrote:
> On Sun, 25 Nov 2018 05:51:32 -0800
> Matt Ranostay wrote:
>
> > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> > >
> > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > is de facto standard. Existing air quality sensors usually follow
> > > this convention and are capable of returning measurements using
> > > this unit.
> > >
> > > IIO currently does not offer suitable channel type for this
> > > type of measurements hence this patch adds this.
> > >
> > > In addition, two modifiers are introduced used for distinguishing
> > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > >
> > > Signed-off-by: Tomasz Duszynski
> > > ---
> > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > drivers/iio/industrialio-core.c | 3 +++
> > > include/uapi/linux/iio/types.h | 3 +++
> > > tools/iio/iio_event_monitor.c | 6 ++
> > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > index 8127a08e366d..ce0ed140660d 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > Contact: linux-...@vger.kernel.org
> > > Description:
> > > Raw (unscaled) phase difference reading from channel Y
> > > - that can be processed to radians.
> > > \ No newline at end of file
> > > + that can be processed to radians.
> > > +
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > +KernelVersion: 4.21
> > > +Contact: linux-...@vger.kernel.org
> > > +Description:
> > > + Mass concentration reading of particulate matter in ug /
> > > m3.
> > > diff --git a/drivers/iio/industrialio-core.c
> > > b/drivers/iio/industrialio-core.c
> > > index a062cfddc5af..2a9ef600c1fb 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > > [IIO_GRAVITY] = "gravity",
> > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > [IIO_PHASE] = "phase",
> > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > };
> > >
> > > static const char * const iio_modifier_names[] = {
> > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > [IIO_MOD_Q] = "q",
> > > [IIO_MOD_CO2] = "co2",
> > > [IIO_MOD_VOC] = "voc",
> > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > + [IIO_MOD_PM10] = "pm10",
> > > };
> > >
> > > /* relies on pairs of these shared then separate */
> > > diff --git a/include/uapi/linux/iio/types.h
> > > b/include/uapi/linux/iio/types.h
> > > index 92baabc103ac..465044b42af5 100644
> > > --- a/include/uapi/linux/iio/types.h
> > > +++ b/include/uapi/linux/iio/types.h
> > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > IIO_GRAVITY,
> > > IIO_POSITIONRELATIVE,
> > > IIO_PHASE,
> > > + IIO_MASSCONCENTRATION,
> >
> > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > per cubic meter?
>
> Currently concentration is defined as a percentage reading of a substance
> (which does make me wonder if it is meant to be percentage of the volume or
> percentage of the mass?) Either way, if can't convert to a density
> measurement
> as it's a unit free ratio (I think).
>
And this is the main reason behind introducing a new channel type.
> >
> > > };
> > >
> > > enum iio_modifier {
> > > @@ -87,6 +88,8 @@ enum iio_modifier {
> > > IIO_MOD_VOC,
> > > IIO_MOD_LIGHT_UV,
> > > IIO_MOD_LIGHT_DUV,
> > > + IIO_MOD_PM2p5,
> >
> > I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> > a bit non-standard for iio defines/enum.
> It is a bit odd and will get us scripted reports so maybe best to
> just go upper case and not worry about it.
>
Initially I came up with IIO_MOD_PM2_5 but eventually replaced
underscore with 'p' meaning 'decimal point'. Anyway, I am okay with the
suggested change.
> Jonathan
> >
> > - Matt
> >
> > > + IIO_MOD_PM10,
> > > };
> > >
> > > enum iio_event_type {
> > > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > > index ac2de6b7e89f..f0fcfeddba2b 100644
> > > --- a/tools/iio/iio_event_monitor.c
> > > +++ b/tools/iio/iio_event_monitor.c
> > > @@ -60,6 +60,7 @@ static const char *
WARNING: bad usercopy in corrupted (2)
Hello, syzbot found the following crash on: HEAD commit:aea0a897af9e ptp: Fix pass zero to ERR_PTR() in ptp_clock_.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=101b91d540 kernel config: https://syzkaller.appspot.com/x/.config?x=c36a72af2123e78a dashboard link: https://syzkaller.appspot.com/bug?extid=d89b30c46434c433dbf8 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=170f6a4740 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e1df7b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d89b30c46434c433d...@syzkaller.appspotmail.com [ cut here ] DEBUG_LOCKS_WARN_ON(!hlock->nest_lock) [ cut here ] Bad or missing usercopy whitelist? Kernel memory overwrite attempt detected to SLAB object 'task_struct' (offset 1432, size 2)! WARNING: CPU: 1 PID: 38 at mm/usercopy.c:83 usercopy_warn+0xee/0x110 mm/usercopy.c:78 Kernel panic - not syncing: panic_on_warn set ... list_add corruption. next->prev should be prev (8881daf2d798), but was 0b7e0c8e49cc0400. (next=8881d9b4a4f0). CPU: 1 PID: 38 Comm: ���ف���d �� Not tainted 4.20.0-rc3+ #312 [ cut here ] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 kernel BUG at lib/list_debug.c:25! [ cut here ] invalid opcode: [#1] PREEMPT SMP KASAN kernel BUG at mm/slab.c:4425! CPU: 0 PID: 8652 Comm: syz-executor607 Not tainted 4.20.0-rc3+ #312 WARNING: CPU: 1 PID: 38 at kernel/rcu/tree_plugin.h:438 __rcu_read_unlock+0x266/0x2e0 kernel/rcu/tree_plugin.h:432 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Modules linked in: RIP: 0010:__list_add_valid.cold.2+0xf/0x2a lib/list_debug.c:23 CPU: 1 PID: 38 Comm: ���ف���d �� Not tainted 4.20.0-rc3+ #312 Code: d1 60 88 e8 a1 37 d2 fd 0f 0b 48 89 de 48 c7 c7 60 d1 60 88 e8 90 37 d2 fd 0f 0b 48 89 d9 48 c7 c7 20 d2 60 88 e8 7f 37 d2 fd <0f> 0b 48 89 f1 48 c7 c7 a0 d2 60 88 48 89 de e8 6b 37 d2 fd 0f 0b Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RSP: :8881dae07588 EFLAGS: 00010082 usercopy: Kernel memory overwrite attempt detected to SLAB object 'signal_cache' (offset 1328, size 23)! RAX: 0075 RBX: 8881d9b4a4f0 RCX: [ cut here ] RDX: RSI: 8165eaf5 RDI: 0005 kernel BUG at mm/usercopy.c:102! RBP: 8881dae075a0 R08: 8881d25ce100 R09: ed103b5c5020 R10: ed103b5c5020 R11: 8881dae28107 R12: 8881bd890230 R13: dc00 R14: 8881dae07980 R15: 8881daf2d798 FS: 0083c880() GS:8881dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fff14476600 CR3: 0001d2a59000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __list_add include/linux/list.h:60 [inline] list_add include/linux/list.h:79 [inline] list_move include/linux/list.h:171 [inline] detach_tasks kernel/sched/fair.c:7298 [inline] load_balance+0x1b8d/0x39a0 kernel/sched/fair.c:8731 rebalance_domains+0x845/0xdc0 kernel/sched/fair.c:9109 run_rebalance_domains+0x38d/0x500 kernel/sched/fair.c:9731 __do_softirq+0x308/0xb7e kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x17f/0x1c0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:804 RIP: 0033:0x4005dd Code: c9 00 04 00 66 0f 1f 84 00 00 00 00 00 48 8b 05 f1 2e 2d 00 48 85 c0 74 11 bf 3c e8 4b 00 b9 0e 00 00 00 48 89 c6 f3 a6 75 01 48 89 c7 e9 9a ec 01 00 66 2e 0f 1f 84 00 00 00 00 00 8b 05 4a RSP: 002b:7fff144765a8 EFLAGS: 0246 ORIG_RAX: ff13 RAX: RBX: 0002 RCX: 006d2190 RDX: 00402410 RSI: RDI: RBP: 006cc0a8 R08: R09: R10: R11: 0246 R12: 0001 R13: 006d2180 R14: R15: Modules linked in: ---[ end trace eeb5734c13709e17 ]--- invalid opcode: [#2] PREEMPT SMP KASAN CPU: 1 PID: 38 Comm: ���ف���d �� Tainted: G D 4.20.0-rc3+ #312 RIP: 0010:__list_add_valid.cold.2+0xf/0x2a lib/list_debug.c:23 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Code: d1 60 88 e8 a1 37 d2 fd 0f 0b 48 89 de 48 c7 c7 60 d1 60 88 e8 90 37 d2 fd 0f 0b 48 89 d9 48 c7 c7 20 d2 60 88 e8 7f 37 d2 fd <0f> 0b 48 89 f1 48 c7 c7 a0 d2 60 88 48 89 de
WARNING: bad usercopy in corrupted (2)
Hello, syzbot found the following crash on: HEAD commit:aea0a897af9e ptp: Fix pass zero to ERR_PTR() in ptp_clock_.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=101b91d540 kernel config: https://syzkaller.appspot.com/x/.config?x=c36a72af2123e78a dashboard link: https://syzkaller.appspot.com/bug?extid=d89b30c46434c433dbf8 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=170f6a4740 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e1df7b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d89b30c46434c433d...@syzkaller.appspotmail.com [ cut here ] DEBUG_LOCKS_WARN_ON(!hlock->nest_lock) [ cut here ] Bad or missing usercopy whitelist? Kernel memory overwrite attempt detected to SLAB object 'task_struct' (offset 1432, size 2)! WARNING: CPU: 1 PID: 38 at mm/usercopy.c:83 usercopy_warn+0xee/0x110 mm/usercopy.c:78 Kernel panic - not syncing: panic_on_warn set ... list_add corruption. next->prev should be prev (8881daf2d798), but was 0b7e0c8e49cc0400. (next=8881d9b4a4f0). CPU: 1 PID: 38 Comm: ���ف���d �� Not tainted 4.20.0-rc3+ #312 [ cut here ] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 kernel BUG at lib/list_debug.c:25! [ cut here ] invalid opcode: [#1] PREEMPT SMP KASAN kernel BUG at mm/slab.c:4425! CPU: 0 PID: 8652 Comm: syz-executor607 Not tainted 4.20.0-rc3+ #312 WARNING: CPU: 1 PID: 38 at kernel/rcu/tree_plugin.h:438 __rcu_read_unlock+0x266/0x2e0 kernel/rcu/tree_plugin.h:432 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Modules linked in: RIP: 0010:__list_add_valid.cold.2+0xf/0x2a lib/list_debug.c:23 CPU: 1 PID: 38 Comm: ���ف���d �� Not tainted 4.20.0-rc3+ #312 Code: d1 60 88 e8 a1 37 d2 fd 0f 0b 48 89 de 48 c7 c7 60 d1 60 88 e8 90 37 d2 fd 0f 0b 48 89 d9 48 c7 c7 20 d2 60 88 e8 7f 37 d2 fd <0f> 0b 48 89 f1 48 c7 c7 a0 d2 60 88 48 89 de e8 6b 37 d2 fd 0f 0b Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RSP: :8881dae07588 EFLAGS: 00010082 usercopy: Kernel memory overwrite attempt detected to SLAB object 'signal_cache' (offset 1328, size 23)! RAX: 0075 RBX: 8881d9b4a4f0 RCX: [ cut here ] RDX: RSI: 8165eaf5 RDI: 0005 kernel BUG at mm/usercopy.c:102! RBP: 8881dae075a0 R08: 8881d25ce100 R09: ed103b5c5020 R10: ed103b5c5020 R11: 8881dae28107 R12: 8881bd890230 R13: dc00 R14: 8881dae07980 R15: 8881daf2d798 FS: 0083c880() GS:8881dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fff14476600 CR3: 0001d2a59000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __list_add include/linux/list.h:60 [inline] list_add include/linux/list.h:79 [inline] list_move include/linux/list.h:171 [inline] detach_tasks kernel/sched/fair.c:7298 [inline] load_balance+0x1b8d/0x39a0 kernel/sched/fair.c:8731 rebalance_domains+0x845/0xdc0 kernel/sched/fair.c:9109 run_rebalance_domains+0x38d/0x500 kernel/sched/fair.c:9731 __do_softirq+0x308/0xb7e kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x17f/0x1c0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:804 RIP: 0033:0x4005dd Code: c9 00 04 00 66 0f 1f 84 00 00 00 00 00 48 8b 05 f1 2e 2d 00 48 85 c0 74 11 bf 3c e8 4b 00 b9 0e 00 00 00 48 89 c6 f3 a6 75 01 48 89 c7 e9 9a ec 01 00 66 2e 0f 1f 84 00 00 00 00 00 8b 05 4a RSP: 002b:7fff144765a8 EFLAGS: 0246 ORIG_RAX: ff13 RAX: RBX: 0002 RCX: 006d2190 RDX: 00402410 RSI: RDI: RBP: 006cc0a8 R08: R09: R10: R11: 0246 R12: 0001 R13: 006d2180 R14: R15: Modules linked in: ---[ end trace eeb5734c13709e17 ]--- invalid opcode: [#2] PREEMPT SMP KASAN CPU: 1 PID: 38 Comm: ���ف���d �� Tainted: G D 4.20.0-rc3+ #312 RIP: 0010:__list_add_valid.cold.2+0xf/0x2a lib/list_debug.c:23 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Code: d1 60 88 e8 a1 37 d2 fd 0f 0b 48 89 de 48 c7 c7 60 d1 60 88 e8 90 37 d2 fd 0f 0b 48 89 d9 48 c7 c7 20 d2 60 88 e8 7f 37 d2 fd <0f> 0b 48 89 f1 48 c7 c7 a0 d2 60 88 48 89 de
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 08:35:07AM +, Jonathan Cameron wrote:
> On Sat, 24 Nov 2018 23:14:13 +0100
> Tomasz Duszynski wrote:
>
> > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > is de facto standard. Existing air quality sensors usually follow
> > this convention and are capable of returning measurements using
> > this unit.
> >
> > IIO currently does not offer suitable channel type for this
> > type of measurements hence this patch adds this.
> >
> > In addition, two modifiers are introduced used for distinguishing
> > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> I initially wondered why these particular numbers and why don't
> we provide an attribute specify this separately?
>
> However google suggests these two are pretty much the only
> ones anyone worries about in pollution sensors. I ended
> up fairly quickly at the EPA website
> https://www.epa.gov/pm-pollution/table-historical-particulate-matter-pm-national-ambient-air-quality-standards-naaqs
> which tells me these two have be used since about 1987.
>
Usually sensors can measure more than just PM10 and PM2.5. Fairy
common is measurement of PM1.0. SPS30 additionally measures PM4.0
but frankly I don't now know exactly what's the real usecase for that.
> So I think the modifier route is the right approach here
> (I think we've gotten this wrong in the past such as light
> sensor colours where the list keeps on growing).
>
> I would like a reference or two in the docs though to point
> people to these definitions.
>
Okay, will add something reasonable so everyone interested
could get the basic idea quickly.
> Thanks,
>
> Jonathan
>
> >
> > Signed-off-by: Tomasz Duszynski
> > ---
> > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > drivers/iio/industrialio-core.c | 3 +++
> > include/uapi/linux/iio/types.h | 3 +++
> > tools/iio/iio_event_monitor.c | 6 ++
> > 4 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > b/Documentation/ABI/testing/sysfs-bus-iio
> > index 8127a08e366d..ce0ed140660d 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > Contact: linux-...@vger.kernel.org
> > Description:
> > Raw (unscaled) phase difference reading from channel Y
> > - that can be processed to radians.
> > \ No newline at end of file
> > + that can be processed to radians.
> > +
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > +KernelVersion: 4.21
> > +Contact: linux-...@vger.kernel.org
> > +Description:
> > + Mass concentration reading of particulate matter in ug / m3.
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index a062cfddc5af..2a9ef600c1fb 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > };
> >
> > static const char * const iio_modifier_names[] = {
> > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > [IIO_MOD_Q] = "q",
> > [IIO_MOD_CO2] = "co2",
> > [IIO_MOD_VOC] = "voc",
> > + [IIO_MOD_PM2p5] = "pm2p5",
> > + [IIO_MOD_PM10] = "pm10",
> > };
> >
> > /* relies on pairs of these shared then separate */
> > diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> > index 92baabc103ac..465044b42af5 100644
> > --- a/include/uapi/linux/iio/types.h
> > +++ b/include/uapi/linux/iio/types.h
> > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > IIO_GRAVITY,
> > IIO_POSITIONRELATIVE,
> > IIO_PHASE,
> > + IIO_MASSCONCENTRATION,
> > };
> >
> > enum iio_modifier {
> > @@ -87,6 +88,8 @@ enum iio_modifier {
> > IIO_MOD_VOC,
> > IIO_MOD_LIGHT_UV,
> > IIO_MOD_LIGHT_DUV,
> > + IIO_MOD_PM2p5,
> > + IIO_MOD_PM10,
> > };
> >
> > enum iio_event_type {
> > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > index ac2de6b7e89f..f0fcfeddba2b 100644
> > --- a/tools/iio/iio_event_monitor.c
> > +++ b/tools/iio/iio_event_monitor.c
> > @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > +
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 08:35:07AM +, Jonathan Cameron wrote:
> On Sat, 24 Nov 2018 23:14:13 +0100
> Tomasz Duszynski wrote:
>
> > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > is de facto standard. Existing air quality sensors usually follow
> > this convention and are capable of returning measurements using
> > this unit.
> >
> > IIO currently does not offer suitable channel type for this
> > type of measurements hence this patch adds this.
> >
> > In addition, two modifiers are introduced used for distinguishing
> > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> I initially wondered why these particular numbers and why don't
> we provide an attribute specify this separately?
>
> However google suggests these two are pretty much the only
> ones anyone worries about in pollution sensors. I ended
> up fairly quickly at the EPA website
> https://www.epa.gov/pm-pollution/table-historical-particulate-matter-pm-national-ambient-air-quality-standards-naaqs
> which tells me these two have be used since about 1987.
>
Usually sensors can measure more than just PM10 and PM2.5. Fairy
common is measurement of PM1.0. SPS30 additionally measures PM4.0
but frankly I don't now know exactly what's the real usecase for that.
> So I think the modifier route is the right approach here
> (I think we've gotten this wrong in the past such as light
> sensor colours where the list keeps on growing).
>
> I would like a reference or two in the docs though to point
> people to these definitions.
>
Okay, will add something reasonable so everyone interested
could get the basic idea quickly.
> Thanks,
>
> Jonathan
>
> >
> > Signed-off-by: Tomasz Duszynski
> > ---
> > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > drivers/iio/industrialio-core.c | 3 +++
> > include/uapi/linux/iio/types.h | 3 +++
> > tools/iio/iio_event_monitor.c | 6 ++
> > 4 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > b/Documentation/ABI/testing/sysfs-bus-iio
> > index 8127a08e366d..ce0ed140660d 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > Contact: linux-...@vger.kernel.org
> > Description:
> > Raw (unscaled) phase difference reading from channel Y
> > - that can be processed to radians.
> > \ No newline at end of file
> > + that can be processed to radians.
> > +
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > +KernelVersion: 4.21
> > +Contact: linux-...@vger.kernel.org
> > +Description:
> > + Mass concentration reading of particulate matter in ug / m3.
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index a062cfddc5af..2a9ef600c1fb 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > };
> >
> > static const char * const iio_modifier_names[] = {
> > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > [IIO_MOD_Q] = "q",
> > [IIO_MOD_CO2] = "co2",
> > [IIO_MOD_VOC] = "voc",
> > + [IIO_MOD_PM2p5] = "pm2p5",
> > + [IIO_MOD_PM10] = "pm10",
> > };
> >
> > /* relies on pairs of these shared then separate */
> > diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> > index 92baabc103ac..465044b42af5 100644
> > --- a/include/uapi/linux/iio/types.h
> > +++ b/include/uapi/linux/iio/types.h
> > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > IIO_GRAVITY,
> > IIO_POSITIONRELATIVE,
> > IIO_PHASE,
> > + IIO_MASSCONCENTRATION,
> > };
> >
> > enum iio_modifier {
> > @@ -87,6 +88,8 @@ enum iio_modifier {
> > IIO_MOD_VOC,
> > IIO_MOD_LIGHT_UV,
> > IIO_MOD_LIGHT_DUV,
> > + IIO_MOD_PM2p5,
> > + IIO_MOD_PM10,
> > };
> >
> > enum iio_event_type {
> > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > index ac2de6b7e89f..f0fcfeddba2b 100644
> > --- a/tools/iio/iio_event_monitor.c
> > +++ b/tools/iio/iio_event_monitor.c
> > @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > +
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: > On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > > > At a high level, addressing these issues is straight forward. First, > > > the driver needs to support authorization equivalent to that which is > > > implemented in the current Intel Launch Enclave, ie. control over the > > > SGX_FLAGS_PROVISION_KEY attribute. > > > > I agree, hence my email :) > > Started to scratch my head that is it really an issue that any enclave > can provision in the end? > > Direct quote from your first response: > > "In particular, the ability to run enclaves with the provisioning bit set > is somewhat sensitive, since it effectively allows access to a stable > fingerprint of the system." > > As can be seen from the key derivation table this does not exactly hold > so you should refine your original argument before we can consider any > type of change. > > I just don't see what it is so wrong for any enclave to be able to tell > that it really is an enclave. I mean I can understand why Greg wants LE although I don't understand what benefit does it bring to anyone to lock in for enclave to allow to identify itself. What you are proposing does not really bring any additional security if we consider a threat model where the kernel is an adversary but it makes the software stack more clanky to use. /Jarkko
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: > On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > > > At a high level, addressing these issues is straight forward. First, > > > the driver needs to support authorization equivalent to that which is > > > implemented in the current Intel Launch Enclave, ie. control over the > > > SGX_FLAGS_PROVISION_KEY attribute. > > > > I agree, hence my email :) > > Started to scratch my head that is it really an issue that any enclave > can provision in the end? > > Direct quote from your first response: > > "In particular, the ability to run enclaves with the provisioning bit set > is somewhat sensitive, since it effectively allows access to a stable > fingerprint of the system." > > As can be seen from the key derivation table this does not exactly hold > so you should refine your original argument before we can consider any > type of change. > > I just don't see what it is so wrong for any enclave to be able to tell > that it really is an enclave. I mean I can understand why Greg wants LE although I don't understand what benefit does it bring to anyone to lock in for enclave to allow to identify itself. What you are proposing does not really bring any additional security if we consider a threat model where the kernel is an adversary but it makes the software stack more clanky to use. /Jarkko
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
wrote:
>
> On Sun, 25 Nov 2018 05:51:32 -0800
> Matt Ranostay wrote:
>
> > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> > >
> > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > is de facto standard. Existing air quality sensors usually follow
> > > this convention and are capable of returning measurements using
> > > this unit.
> > >
> > > IIO currently does not offer suitable channel type for this
> > > type of measurements hence this patch adds this.
> > >
> > > In addition, two modifiers are introduced used for distinguishing
> > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > >
> > > Signed-off-by: Tomasz Duszynski
> > > ---
> > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > drivers/iio/industrialio-core.c | 3 +++
> > > include/uapi/linux/iio/types.h | 3 +++
> > > tools/iio/iio_event_monitor.c | 6 ++
> > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > index 8127a08e366d..ce0ed140660d 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > Contact: linux-...@vger.kernel.org
> > > Description:
> > > Raw (unscaled) phase difference reading from channel Y
> > > - that can be processed to radians.
> > > \ No newline at end of file
> > > + that can be processed to radians.
> > > +
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > +KernelVersion: 4.21
> > > +Contact: linux-...@vger.kernel.org
> > > +Description:
> > > + Mass concentration reading of particulate matter in ug /
> > > m3.
> > > diff --git a/drivers/iio/industrialio-core.c
> > > b/drivers/iio/industrialio-core.c
> > > index a062cfddc5af..2a9ef600c1fb 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > > [IIO_GRAVITY] = "gravity",
> > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > [IIO_PHASE] = "phase",
> > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > };
> > >
> > > static const char * const iio_modifier_names[] = {
> > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > [IIO_MOD_Q] = "q",
> > > [IIO_MOD_CO2] = "co2",
> > > [IIO_MOD_VOC] = "voc",
> > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > + [IIO_MOD_PM10] = "pm10",
> > > };
> > >
> > > /* relies on pairs of these shared then separate */
> > > diff --git a/include/uapi/linux/iio/types.h
> > > b/include/uapi/linux/iio/types.h
> > > index 92baabc103ac..465044b42af5 100644
> > > --- a/include/uapi/linux/iio/types.h
> > > +++ b/include/uapi/linux/iio/types.h
> > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > IIO_GRAVITY,
> > > IIO_POSITIONRELATIVE,
> > > IIO_PHASE,
> > > + IIO_MASSCONCENTRATION,
> >
> > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > per cubic meter?
>
> Currently concentration is defined as a percentage reading of a substance
> (which does make me wonder if it is meant to be percentage of the volume or
> percentage of the mass?) Either way, if can't convert to a density
> measurement
> as it's a unit free ratio (I think).
Seems like it can be both.. guessing all the atmosphere ( CO2, VOC,
etc) ones are mass/density because on how they work.
But the electro-conductivity sensor that is using IIO_CONCENTRATION
channels is likely from percentage of volume.
- Matt
>
> >
> > > };
> > >
> > > enum iio_modifier {
> > > @@ -87,6 +88,8 @@ enum iio_modifier {
> > > IIO_MOD_VOC,
> > > IIO_MOD_LIGHT_UV,
> > > IIO_MOD_LIGHT_DUV,
> > > + IIO_MOD_PM2p5,
> >
> > I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> > a bit non-standard for iio defines/enum.
> It is a bit odd and will get us scripted reports so maybe best to
> just go upper case and not worry about it.
>
> Jonathan
> >
> > - Matt
> >
> > > + IIO_MOD_PM10,
> > > };
> > >
> > > enum iio_event_type {
> > > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > > index ac2de6b7e89f..f0fcfeddba2b 100644
> > > --- a/tools/iio/iio_event_monitor.c
> > > +++ b/tools/iio/iio_event_monitor.c
> > > @@ -60,6 +60,7 @@ static
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
wrote:
>
> On Sun, 25 Nov 2018 05:51:32 -0800
> Matt Ranostay wrote:
>
> > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> > >
> > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > is de facto standard. Existing air quality sensors usually follow
> > > this convention and are capable of returning measurements using
> > > this unit.
> > >
> > > IIO currently does not offer suitable channel type for this
> > > type of measurements hence this patch adds this.
> > >
> > > In addition, two modifiers are introduced used for distinguishing
> > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > >
> > > Signed-off-by: Tomasz Duszynski
> > > ---
> > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > drivers/iio/industrialio-core.c | 3 +++
> > > include/uapi/linux/iio/types.h | 3 +++
> > > tools/iio/iio_event_monitor.c | 6 ++
> > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > index 8127a08e366d..ce0ed140660d 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > Contact: linux-...@vger.kernel.org
> > > Description:
> > > Raw (unscaled) phase difference reading from channel Y
> > > - that can be processed to radians.
> > > \ No newline at end of file
> > > + that can be processed to radians.
> > > +
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > +KernelVersion: 4.21
> > > +Contact: linux-...@vger.kernel.org
> > > +Description:
> > > + Mass concentration reading of particulate matter in ug /
> > > m3.
> > > diff --git a/drivers/iio/industrialio-core.c
> > > b/drivers/iio/industrialio-core.c
> > > index a062cfddc5af..2a9ef600c1fb 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > > [IIO_GRAVITY] = "gravity",
> > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > [IIO_PHASE] = "phase",
> > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > };
> > >
> > > static const char * const iio_modifier_names[] = {
> > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > [IIO_MOD_Q] = "q",
> > > [IIO_MOD_CO2] = "co2",
> > > [IIO_MOD_VOC] = "voc",
> > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > + [IIO_MOD_PM10] = "pm10",
> > > };
> > >
> > > /* relies on pairs of these shared then separate */
> > > diff --git a/include/uapi/linux/iio/types.h
> > > b/include/uapi/linux/iio/types.h
> > > index 92baabc103ac..465044b42af5 100644
> > > --- a/include/uapi/linux/iio/types.h
> > > +++ b/include/uapi/linux/iio/types.h
> > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > IIO_GRAVITY,
> > > IIO_POSITIONRELATIVE,
> > > IIO_PHASE,
> > > + IIO_MASSCONCENTRATION,
> >
> > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > per cubic meter?
>
> Currently concentration is defined as a percentage reading of a substance
> (which does make me wonder if it is meant to be percentage of the volume or
> percentage of the mass?) Either way, if can't convert to a density
> measurement
> as it's a unit free ratio (I think).
Seems like it can be both.. guessing all the atmosphere ( CO2, VOC,
etc) ones are mass/density because on how they work.
But the electro-conductivity sensor that is using IIO_CONCENTRATION
channels is likely from percentage of volume.
- Matt
>
> >
> > > };
> > >
> > > enum iio_modifier {
> > > @@ -87,6 +88,8 @@ enum iio_modifier {
> > > IIO_MOD_VOC,
> > > IIO_MOD_LIGHT_UV,
> > > IIO_MOD_LIGHT_DUV,
> > > + IIO_MOD_PM2p5,
> >
> > I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> > a bit non-standard for iio defines/enum.
> It is a bit odd and will get us scripted reports so maybe best to
> just go upper case and not worry about it.
>
> Jonathan
> >
> > - Matt
> >
> > > + IIO_MOD_PM10,
> > > };
> > >
> > > enum iio_event_type {
> > > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > > index ac2de6b7e89f..f0fcfeddba2b 100644
> > > --- a/tools/iio/iio_event_monitor.c
> > > +++ b/tools/iio/iio_event_monitor.c
> > > @@ -60,6 +60,7 @@ static
Re: [PATCH] iio: hid-sensor-hub: clean up indentation, remove extraneous tab
On Sun, 18 Nov 2018 16:27:57 +
Colin King wrote:
> From: Colin Ian King
>
> The statement is indented too much by one level, fix this by
> removing the extraneous tab.
>
> Signed-off-by: Colin Ian King
Applied to the togreg branch of iio.git and pushed out as testing
because lots of other stuff in there needs build testing.
thanks,
Jonathan
> ---
> drivers/iio/common/hid-sensors/hid-sensor-attributes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> index ed3849d6fc6a..b2143d7b4ccb 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> @@ -336,7 +336,7 @@ static void adjust_exponent_nano(int *val0, int *val1,
> int scale0,
> scale1 = scale1 % pow_10(8 - i);
> }
> *val0 += res;
> - *val1 = scale1 * pow_10(exp);
> + *val1 = scale1 * pow_10(exp);
> } else if (exp < 0) {
> exp = abs(exp);
> if (exp > 9) {
Re: [PATCH] iio: hid-sensor-hub: clean up indentation, remove extraneous tab
On Sun, 18 Nov 2018 16:27:57 +
Colin King wrote:
> From: Colin Ian King
>
> The statement is indented too much by one level, fix this by
> removing the extraneous tab.
>
> Signed-off-by: Colin Ian King
Applied to the togreg branch of iio.git and pushed out as testing
because lots of other stuff in there needs build testing.
thanks,
Jonathan
> ---
> drivers/iio/common/hid-sensors/hid-sensor-attributes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> index ed3849d6fc6a..b2143d7b4ccb 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> @@ -336,7 +336,7 @@ static void adjust_exponent_nano(int *val0, int *val1,
> int scale0,
> scale1 = scale1 % pow_10(8 - i);
> }
> *val0 += res;
> - *val1 = scale1 * pow_10(exp);
> + *val1 = scale1 * pow_10(exp);
> } else if (exp < 0) {
> exp = abs(exp);
> if (exp > 9) {
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, 25 Nov 2018 05:51:32 -0800
Matt Ranostay wrote:
> On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> >
> > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > is de facto standard. Existing air quality sensors usually follow
> > this convention and are capable of returning measurements using
> > this unit.
> >
> > IIO currently does not offer suitable channel type for this
> > type of measurements hence this patch adds this.
> >
> > In addition, two modifiers are introduced used for distinguishing
> > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> >
> > Signed-off-by: Tomasz Duszynski
> > ---
> > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > drivers/iio/industrialio-core.c | 3 +++
> > include/uapi/linux/iio/types.h | 3 +++
> > tools/iio/iio_event_monitor.c | 6 ++
> > 4 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > b/Documentation/ABI/testing/sysfs-bus-iio
> > index 8127a08e366d..ce0ed140660d 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > Contact: linux-...@vger.kernel.org
> > Description:
> > Raw (unscaled) phase difference reading from channel Y
> > - that can be processed to radians.
> > \ No newline at end of file
> > + that can be processed to radians.
> > +
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > +KernelVersion: 4.21
> > +Contact: linux-...@vger.kernel.org
> > +Description:
> > + Mass concentration reading of particulate matter in ug / m3.
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index a062cfddc5af..2a9ef600c1fb 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > };
> >
> > static const char * const iio_modifier_names[] = {
> > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > [IIO_MOD_Q] = "q",
> > [IIO_MOD_CO2] = "co2",
> > [IIO_MOD_VOC] = "voc",
> > + [IIO_MOD_PM2p5] = "pm2p5",
> > + [IIO_MOD_PM10] = "pm10",
> > };
> >
> > /* relies on pairs of these shared then separate */
> > diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> > index 92baabc103ac..465044b42af5 100644
> > --- a/include/uapi/linux/iio/types.h
> > +++ b/include/uapi/linux/iio/types.h
> > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > IIO_GRAVITY,
> > IIO_POSITIONRELATIVE,
> > IIO_PHASE,
> > + IIO_MASSCONCENTRATION,
>
> So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> per cubic meter?
Currently concentration is defined as a percentage reading of a substance
(which does make me wonder if it is meant to be percentage of the volume or
percentage of the mass?) Either way, if can't convert to a density measurement
as it's a unit free ratio (I think).
>
> > };
> >
> > enum iio_modifier {
> > @@ -87,6 +88,8 @@ enum iio_modifier {
> > IIO_MOD_VOC,
> > IIO_MOD_LIGHT_UV,
> > IIO_MOD_LIGHT_DUV,
> > + IIO_MOD_PM2p5,
>
> I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> a bit non-standard for iio defines/enum.
It is a bit odd and will get us scripted reports so maybe best to
just go upper case and not worry about it.
Jonathan
>
> - Matt
>
> > + IIO_MOD_PM10,
> > };
> >
> > enum iio_event_type {
> > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > index ac2de6b7e89f..f0fcfeddba2b 100644
> > --- a/tools/iio/iio_event_monitor.c
> > +++ b/tools/iio/iio_event_monitor.c
> > @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > };
> >
> > static const char * const iio_ev_type_text[] = {
> > @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> > [IIO_MOD_Q] = "q",
> > [IIO_MOD_CO2] = "co2",
> > [IIO_MOD_VOC] = "voc",
> > + [IIO_MOD_PM2p5] = "pm2p5",
> > +
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, 25 Nov 2018 05:51:32 -0800
Matt Ranostay wrote:
> On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> >
> > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > is de facto standard. Existing air quality sensors usually follow
> > this convention and are capable of returning measurements using
> > this unit.
> >
> > IIO currently does not offer suitable channel type for this
> > type of measurements hence this patch adds this.
> >
> > In addition, two modifiers are introduced used for distinguishing
> > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> >
> > Signed-off-by: Tomasz Duszynski
> > ---
> > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > drivers/iio/industrialio-core.c | 3 +++
> > include/uapi/linux/iio/types.h | 3 +++
> > tools/iio/iio_event_monitor.c | 6 ++
> > 4 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > b/Documentation/ABI/testing/sysfs-bus-iio
> > index 8127a08e366d..ce0ed140660d 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > Contact: linux-...@vger.kernel.org
> > Description:
> > Raw (unscaled) phase difference reading from channel Y
> > - that can be processed to radians.
> > \ No newline at end of file
> > + that can be processed to radians.
> > +
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > +KernelVersion: 4.21
> > +Contact: linux-...@vger.kernel.org
> > +Description:
> > + Mass concentration reading of particulate matter in ug / m3.
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index a062cfddc5af..2a9ef600c1fb 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > };
> >
> > static const char * const iio_modifier_names[] = {
> > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > [IIO_MOD_Q] = "q",
> > [IIO_MOD_CO2] = "co2",
> > [IIO_MOD_VOC] = "voc",
> > + [IIO_MOD_PM2p5] = "pm2p5",
> > + [IIO_MOD_PM10] = "pm10",
> > };
> >
> > /* relies on pairs of these shared then separate */
> > diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> > index 92baabc103ac..465044b42af5 100644
> > --- a/include/uapi/linux/iio/types.h
> > +++ b/include/uapi/linux/iio/types.h
> > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > IIO_GRAVITY,
> > IIO_POSITIONRELATIVE,
> > IIO_PHASE,
> > + IIO_MASSCONCENTRATION,
>
> So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> per cubic meter?
Currently concentration is defined as a percentage reading of a substance
(which does make me wonder if it is meant to be percentage of the volume or
percentage of the mass?) Either way, if can't convert to a density measurement
as it's a unit free ratio (I think).
>
> > };
> >
> > enum iio_modifier {
> > @@ -87,6 +88,8 @@ enum iio_modifier {
> > IIO_MOD_VOC,
> > IIO_MOD_LIGHT_UV,
> > IIO_MOD_LIGHT_DUV,
> > + IIO_MOD_PM2p5,
>
> I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> a bit non-standard for iio defines/enum.
It is a bit odd and will get us scripted reports so maybe best to
just go upper case and not worry about it.
Jonathan
>
> - Matt
>
> > + IIO_MOD_PM10,
> > };
> >
> > enum iio_event_type {
> > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > index ac2de6b7e89f..f0fcfeddba2b 100644
> > --- a/tools/iio/iio_event_monitor.c
> > +++ b/tools/iio/iio_event_monitor.c
> > @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > };
> >
> > static const char * const iio_ev_type_text[] = {
> > @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> > [IIO_MOD_Q] = "q",
> > [IIO_MOD_CO2] = "co2",
> > [IIO_MOD_VOC] = "voc",
> > + [IIO_MOD_PM2p5] = "pm2p5",
> > +
Re: [PATCH v4 1/3] kernel.h: disable type-checks in container_of() for Sparse
On Sat, Nov 24, 2018 at 6:06 PM Miguel Ojeda
wrote:
>
> On Fri, Nov 23, 2018 at 10:14 PM Luc Van Oostenryck
> wrote:
> >
> > On Thu, Nov 22, 2018 at 12:14:20PM +0900, Masahiro Yamada wrote:
> > > When I tried to enable BUILD_BUG_ON for Sparse, the kbuild test robot
> > > reported lots of "unknown expression" warnings from container_of(),
> > > which seemed false positive.
> > >
> > > I addressed this in [1], but fixing Sparse is the right thing to do.
> > >
> > > The issue was fixed by Sparse commit 0eb8175d3e9c ("fix expansion of
> > > function designator"), but it will take time until the fixed version
> > > of Sparse is widely available.
> > >
> > > Disable the container_of() type checks for Sparse for now.
> >
> > I would prefer that developers upgrade their version of sparse but ...
> >
> > Reviewed-by: Luc Van Oostenryck
>
> Indeed. If someone is writing code for the latest kernels, I think it
> is reasonable to assume they are able to use the latest sparse too,
> since it is not required for compilation anyway.
I am OK with either way.
I leave this to Andrew.
--
Best Regards
Masahiro Yamada
Re: [PATCH v4 1/3] kernel.h: disable type-checks in container_of() for Sparse
On Sat, Nov 24, 2018 at 6:06 PM Miguel Ojeda
wrote:
>
> On Fri, Nov 23, 2018 at 10:14 PM Luc Van Oostenryck
> wrote:
> >
> > On Thu, Nov 22, 2018 at 12:14:20PM +0900, Masahiro Yamada wrote:
> > > When I tried to enable BUILD_BUG_ON for Sparse, the kbuild test robot
> > > reported lots of "unknown expression" warnings from container_of(),
> > > which seemed false positive.
> > >
> > > I addressed this in [1], but fixing Sparse is the right thing to do.
> > >
> > > The issue was fixed by Sparse commit 0eb8175d3e9c ("fix expansion of
> > > function designator"), but it will take time until the fixed version
> > > of Sparse is widely available.
> > >
> > > Disable the container_of() type checks for Sparse for now.
> >
> > I would prefer that developers upgrade their version of sparse but ...
> >
> > Reviewed-by: Luc Van Oostenryck
>
> Indeed. If someone is writing code for the latest kernels, I think it
> is reasonable to assume they are able to use the latest sparse too,
> since it is not required for compilation anyway.
I am OK with either way.
I leave this to Andrew.
--
Best Regards
Masahiro Yamada
Re: [PATCH v4 0/2] dmaengine: add UniPhier MIO DMAC driver
On Sat, Nov 24, 2018 at 11:16 PM Vinod Koul wrote: > > On 12-10-18, 01:41, Masahiro Yamada wrote: > > 1/2: DT-binding > > 2/2: driver > > Applied this series, thanks Thanks. > While building I noticed that we get few warns when compiling with > C=1, I would prefer you fix them. Please send fixes on top of the > applied patches. My code is fine. If you are talking about the following, your sparse is too old. Upgrade your sparse. ./include/linux/overflow.h:285:13: error: undefined identifier '__builtin_mul_overflow' ./include/linux/overflow.h:285:13: error: incorrect type in conditional ./include/linux/overflow.h:285:13:got void ./include/linux/overflow.h:287:13: error: undefined identifier '__builtin_add_overflow' ./include/linux/overflow.h:287:13: error: incorrect type in conditional ./include/linux/overflow.h:287:13:got void ./include/linux/overflow.h:285:13: warning: call with no type! ./include/linux/overflow.h:287:13: warning: call with no type! > Thanks > -- > ~Vinod -- Best Regards Masahiro Yamada
Re: [PATCH v4 0/2] dmaengine: add UniPhier MIO DMAC driver
On Sat, Nov 24, 2018 at 11:16 PM Vinod Koul wrote: > > On 12-10-18, 01:41, Masahiro Yamada wrote: > > 1/2: DT-binding > > 2/2: driver > > Applied this series, thanks Thanks. > While building I noticed that we get few warns when compiling with > C=1, I would prefer you fix them. Please send fixes on top of the > applied patches. My code is fine. If you are talking about the following, your sparse is too old. Upgrade your sparse. ./include/linux/overflow.h:285:13: error: undefined identifier '__builtin_mul_overflow' ./include/linux/overflow.h:285:13: error: incorrect type in conditional ./include/linux/overflow.h:285:13:got void ./include/linux/overflow.h:287:13: error: undefined identifier '__builtin_add_overflow' ./include/linux/overflow.h:287:13: error: incorrect type in conditional ./include/linux/overflow.h:287:13:got void ./include/linux/overflow.h:285:13: warning: call with no type! ./include/linux/overflow.h:287:13: warning: call with no type! > Thanks > -- > ~Vinod -- Best Regards Masahiro Yamada
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
>
> Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> is de facto standard. Existing air quality sensors usually follow
> this convention and are capable of returning measurements using
> this unit.
>
> IIO currently does not offer suitable channel type for this
> type of measurements hence this patch adds this.
>
> In addition, two modifiers are introduced used for distinguishing
> between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> IIO_MOD_PM10 and IIO_MOD_PM2p5.
>
> Signed-off-by: Tomasz Duszynski
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> drivers/iio/industrialio-core.c | 3 +++
> include/uapi/linux/iio/types.h | 3 +++
> tools/iio/iio_event_monitor.c | 6 ++
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..ce0ed140660d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> Contact: linux-...@vger.kernel.org
> Description:
> Raw (unscaled) phase difference reading from channel Y
> - that can be processed to radians.
> \ No newline at end of file
> + that can be processed to radians.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> +KernelVersion: 4.21
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Mass concentration reading of particulate matter in ug / m3.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..2a9ef600c1fb 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_modifier_names[] = {
> @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..465044b42af5 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -46,6 +46,7 @@ enum iio_chan_type {
> IIO_GRAVITY,
> IIO_POSITIONRELATIVE,
> IIO_PHASE,
> + IIO_MASSCONCENTRATION,
So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
per cubic meter?
> };
>
> enum iio_modifier {
> @@ -87,6 +88,8 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> + IIO_MOD_PM2p5,
I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
a bit non-standard for iio defines/enum.
- Matt
> + IIO_MOD_PM10,
> };
>
> enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f0fcfeddba2b 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_ev_type_text[] = {
> @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> static bool event_is_known(struct iio_event_data *event)
> @@ -156,6 +159,7 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_GRAVITY:
> case IIO_POSITIONRELATIVE:
> case IIO_PHASE:
> + case IIO_MASSCONCENTRATION:
> break;
> default:
> return false;
> @@ -200,6 +204,8 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_MOD_Q:
> case IIO_MOD_CO2:
> case IIO_MOD_VOC:
> + case IIO_MOD_PM2p5:
> + case IIO_MOD_PM10:
> break;
> default:
> return false;
> --
> 2.19.2
>
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
>
> Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> is de facto standard. Existing air quality sensors usually follow
> this convention and are capable of returning measurements using
> this unit.
>
> IIO currently does not offer suitable channel type for this
> type of measurements hence this patch adds this.
>
> In addition, two modifiers are introduced used for distinguishing
> between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> IIO_MOD_PM10 and IIO_MOD_PM2p5.
>
> Signed-off-by: Tomasz Duszynski
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> drivers/iio/industrialio-core.c | 3 +++
> include/uapi/linux/iio/types.h | 3 +++
> tools/iio/iio_event_monitor.c | 6 ++
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..ce0ed140660d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> Contact: linux-...@vger.kernel.org
> Description:
> Raw (unscaled) phase difference reading from channel Y
> - that can be processed to radians.
> \ No newline at end of file
> + that can be processed to radians.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> +KernelVersion: 4.21
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Mass concentration reading of particulate matter in ug / m3.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..2a9ef600c1fb 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_modifier_names[] = {
> @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..465044b42af5 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -46,6 +46,7 @@ enum iio_chan_type {
> IIO_GRAVITY,
> IIO_POSITIONRELATIVE,
> IIO_PHASE,
> + IIO_MASSCONCENTRATION,
So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
per cubic meter?
> };
>
> enum iio_modifier {
> @@ -87,6 +88,8 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> + IIO_MOD_PM2p5,
I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
a bit non-standard for iio defines/enum.
- Matt
> + IIO_MOD_PM10,
> };
>
> enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f0fcfeddba2b 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_ev_type_text[] = {
> @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> static bool event_is_known(struct iio_event_data *event)
> @@ -156,6 +159,7 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_GRAVITY:
> case IIO_POSITIONRELATIVE:
> case IIO_PHASE:
> + case IIO_MASSCONCENTRATION:
> break;
> default:
> return false;
> @@ -200,6 +204,8 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_MOD_Q:
> case IIO_MOD_CO2:
> case IIO_MOD_VOC:
> + case IIO_MOD_PM2p5:
> + case IIO_MOD_PM10:
> break;
> default:
> return false;
> --
> 2.19.2
>
Re: [PATCH 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
On Mon, 19 Nov 2018 12:12:36 +0530
Vignesh R wrote:
> When performing single ended measurements with TSCADC, its recommended
> to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
> corresponding STEP_CONFIGx register.
> Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
> reference voltage for ADC step needs to be set to VREFP and VREFN
> respectively in STEP_CONFIGx register.
> Without these changes, there may be variation of as much as ~2% in the
> ADC's digital output which is bad for precise measurement.
>
> Signed-off-by: Vignesh R
Given the header changes in mfd and the fact not much is going on with this
driver in IIO at the moment, I'm happy for this to go through the mfd tree.
Acked-by: Jonathan Cameron
Thanks,
Jonathan
> ---
> drivers/iio/adc/ti_am335x_adc.c | 5 -
> include/linux/mfd/ti_am335x_tscadc.h | 4
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index cafb1dcadc48..9d984f2a8ba7 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -142,7 +142,10 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
> stepconfig |= STEPCONFIG_MODE_SWCNT;
>
> tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
> - stepconfig | STEPCONFIG_INP(chan));
> + stepconfig | STEPCONFIG_INP(chan) |
> + STEPCONFIG_INM_ADCREFM |
> + STEPCONFIG_RFP_VREFP |
> + STEPCONFIG_RFM_VREFN);
>
> if (adc_dev->open_delay[i] > STEPDELAY_OPEN_MASK) {
> dev_warn(dev, "chan %d open delay truncating to
> 0x3\n",
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h
> b/include/linux/mfd/ti_am335x_tscadc.h
> index b9a53e013bff..483168403ae5 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -78,6 +78,8 @@
> #define STEPCONFIG_YNN BIT(8)
> #define STEPCONFIG_XNP BIT(9)
> #define STEPCONFIG_YPN BIT(10)
> +#define STEPCONFIG_RFP(val) ((val) << 12)
> +#define STEPCONFIG_RFP_VREFP (0x3 << 12)
> #define STEPCONFIG_INM_MASK (0xF << 15)
> #define STEPCONFIG_INM(val) ((val) << 15)
> #define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8)
> @@ -86,6 +88,8 @@
> #define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4)
> #define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8)
> #define STEPCONFIG_FIFO1 BIT(26)
> +#define STEPCONFIG_RFM(val) ((val) << 23)
> +#define STEPCONFIG_RFM_VREFN (0x3 << 23)
>
> /* Delay register */
> #define STEPDELAY_OPEN_MASK (0x3 << 0)
Re: [PATCH 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
On Mon, 19 Nov 2018 12:12:36 +0530
Vignesh R wrote:
> When performing single ended measurements with TSCADC, its recommended
> to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
> corresponding STEP_CONFIGx register.
> Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
> reference voltage for ADC step needs to be set to VREFP and VREFN
> respectively in STEP_CONFIGx register.
> Without these changes, there may be variation of as much as ~2% in the
> ADC's digital output which is bad for precise measurement.
>
> Signed-off-by: Vignesh R
Given the header changes in mfd and the fact not much is going on with this
driver in IIO at the moment, I'm happy for this to go through the mfd tree.
Acked-by: Jonathan Cameron
Thanks,
Jonathan
> ---
> drivers/iio/adc/ti_am335x_adc.c | 5 -
> include/linux/mfd/ti_am335x_tscadc.h | 4
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index cafb1dcadc48..9d984f2a8ba7 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -142,7 +142,10 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
> stepconfig |= STEPCONFIG_MODE_SWCNT;
>
> tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
> - stepconfig | STEPCONFIG_INP(chan));
> + stepconfig | STEPCONFIG_INP(chan) |
> + STEPCONFIG_INM_ADCREFM |
> + STEPCONFIG_RFP_VREFP |
> + STEPCONFIG_RFM_VREFN);
>
> if (adc_dev->open_delay[i] > STEPDELAY_OPEN_MASK) {
> dev_warn(dev, "chan %d open delay truncating to
> 0x3\n",
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h
> b/include/linux/mfd/ti_am335x_tscadc.h
> index b9a53e013bff..483168403ae5 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -78,6 +78,8 @@
> #define STEPCONFIG_YNN BIT(8)
> #define STEPCONFIG_XNP BIT(9)
> #define STEPCONFIG_YPN BIT(10)
> +#define STEPCONFIG_RFP(val) ((val) << 12)
> +#define STEPCONFIG_RFP_VREFP (0x3 << 12)
> #define STEPCONFIG_INM_MASK (0xF << 15)
> #define STEPCONFIG_INM(val) ((val) << 15)
> #define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8)
> @@ -86,6 +88,8 @@
> #define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4)
> #define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8)
> #define STEPCONFIG_FIFO1 BIT(26)
> +#define STEPCONFIG_RFM(val) ((val) << 23)
> +#define STEPCONFIG_RFM_VREFN (0x3 << 23)
>
> /* Delay register */
> #define STEPDELAY_OPEN_MASK (0x3 << 0)
Re: [PATCH] iio: st_sensors: Fix the sleep time for sampling
On Wed, 21 Nov 2018 13:13:40 +0800 Jian-Hong Pan wrote: > Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道： > > > > Hi Jian, > > > > Not clear to me why should be + instead of *. > > > > ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling > > time) [s] > > 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms] > > n * 1000 * (1/Hz) = n times period in milliseconds (n times sample sampling > > time) [ms] > > > > In your case you assume bootime is in milliseconds. > > Yes, I assume that according to the original comment. > > >Maybe we can change the comment and use 'number of samples ...'. > > Making the meaning more clear is better. > > However, does the bootime of the measurement need as the long time to > be enabled? > If the sampling rate is 1Hz and n is 2, then they will do msleep with > 2000 ms for each st_sensors_read_info_raw. Superficially that seems correct as we need to be sure that a reading has occurred. If you want it to be quicker than the ODR should be set faster so that the reading shows up reasonably quickly. At 1Hz and you want to drop 2 samples, it will indeed take 2 seconds. I'm not understanding why this is unexpected? Jonathan > > Regards, > Jian-Hong Pan > > > > > > > -Original Message- > > From: linux-iio-ow...@vger.kernel.org On > > Behalf Of Jian-Hong Pan > > Sent: Sunday, November 18, 2018 10:12 PM > > To: Jonathan Cameron ; Hartmut Knaack ; > > Lars-Peter Clausen ; Peter Meerwald-Stadler > > ; Dominique Martinet > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > > li...@endlessm.com; Jian-Hong Pan > > Subject: [PATCH] iio: st_sensors: Fix the sleep time for sampling > > > > According to the description of st_sensor_settings and st_sensor_data > > structures' comments: > > - bootime: samples to discard when sensor passing from power-down to > > power-up. > > - odr: Output data rate of the sensor [Hz]. > > > > The sleep time should be > > sdata->sensor_settings->bootime + 1000 / sdata->odr ms. > > > > Signed-off-by: Jian-Hong Pan > > --- > > drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c > > b/drivers/iio/common/st_sensors/st_sensors_core.c > > index 26fbd1bd9413..6b87ea657a92 100644 > > --- a/drivers/iio/common/st_sensors/st_sensors_core.c > > +++ b/drivers/iio/common/st_sensors/st_sensors_core.c > > @@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev *indio_dev, > > if (err < 0) > > goto out; > > > > - msleep((sdata->sensor_settings->bootime * 1000) / > > sdata->odr); > > + msleep(sdata->sensor_settings->bootime + 1000 / sdata->odr); > > err = st_sensors_read_axis_data(indio_dev, ch, val); > > if (err < 0) > > goto out; > > -- > > 2.11.0 > >
Re: [PATCH] iio: st_sensors: Fix the sleep time for sampling
On Wed, 21 Nov 2018 13:13:40 +0800 Jian-Hong Pan wrote: > Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道： > > > > Hi Jian, > > > > Not clear to me why should be + instead of *. > > > > ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling > > time) [s] > > 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms] > > n * 1000 * (1/Hz) = n times period in milliseconds (n times sample sampling > > time) [ms] > > > > In your case you assume bootime is in milliseconds. > > Yes, I assume that according to the original comment. > > >Maybe we can change the comment and use 'number of samples ...'. > > Making the meaning more clear is better. > > However, does the bootime of the measurement need as the long time to > be enabled? > If the sampling rate is 1Hz and n is 2, then they will do msleep with > 2000 ms for each st_sensors_read_info_raw. Superficially that seems correct as we need to be sure that a reading has occurred. If you want it to be quicker than the ODR should be set faster so that the reading shows up reasonably quickly. At 1Hz and you want to drop 2 samples, it will indeed take 2 seconds. I'm not understanding why this is unexpected? Jonathan > > Regards, > Jian-Hong Pan > > > > > > > -Original Message- > > From: linux-iio-ow...@vger.kernel.org On > > Behalf Of Jian-Hong Pan > > Sent: Sunday, November 18, 2018 10:12 PM > > To: Jonathan Cameron ; Hartmut Knaack ; > > Lars-Peter Clausen ; Peter Meerwald-Stadler > > ; Dominique Martinet > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > > li...@endlessm.com; Jian-Hong Pan > > Subject: [PATCH] iio: st_sensors: Fix the sleep time for sampling > > > > According to the description of st_sensor_settings and st_sensor_data > > structures' comments: > > - bootime: samples to discard when sensor passing from power-down to > > power-up. > > - odr: Output data rate of the sensor [Hz]. > > > > The sleep time should be > > sdata->sensor_settings->bootime + 1000 / sdata->odr ms. > > > > Signed-off-by: Jian-Hong Pan > > --- > > drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c > > b/drivers/iio/common/st_sensors/st_sensors_core.c > > index 26fbd1bd9413..6b87ea657a92 100644 > > --- a/drivers/iio/common/st_sensors/st_sensors_core.c > > +++ b/drivers/iio/common/st_sensors/st_sensors_core.c > > @@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev *indio_dev, > > if (err < 0) > > goto out; > > > > - msleep((sdata->sensor_settings->bootime * 1000) / > > sdata->odr); > > + msleep(sdata->sensor_settings->bootime + 1000 / sdata->odr); > > err = st_sensors_read_axis_data(indio_dev, ch, val); > > if (err < 0) > > goto out; > > -- > > 2.11.0 > >
Re: [PATCH 3/3] iio: adc: stm32-adc: switch off running adc when going to low power
On Tue, 20 Nov 2018 11:12:32 +0100
Fabrice Gasnier wrote:
> Switch off ADC when going to low power mode, in case it has been left
> running in buffer mode. Then re-enable it when resuming.
>
> Signed-off-by: Fabrice Gasnier
My suspicion is that we have other drivers not correctly handing this
case, but as far as I can see you have it well covered here.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc.c | 79
> -
> 1 file changed, 63 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index 32c9c61..2a9891c 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -1518,7 +1518,7 @@ static int stm32_adc_dma_start(struct iio_dev
> *indio_dev)
> return 0;
> }
>
> -static int stm32_adc_buffer_postenable(struct iio_dev *indio_dev)
> +static int __stm32_adc_buffer_postenable(struct iio_dev *indio_dev)
> {
> struct stm32_adc *adc = iio_priv(indio_dev);
> struct device *dev = indio_dev->dev.parent;
> @@ -1542,10 +1542,6 @@ static int stm32_adc_buffer_postenable(struct iio_dev
> *indio_dev)
> goto err_clr_trig;
> }
>
> - ret = iio_triggered_buffer_postenable(indio_dev);
> - if (ret < 0)
> - goto err_stop_dma;
> -
> /* Reset adc buffer index */
> adc->bufi = 0;
>
> @@ -1556,9 +1552,6 @@ static int stm32_adc_buffer_postenable(struct iio_dev
> *indio_dev)
>
> return 0;
>
> -err_stop_dma:
> - if (adc->dma_chan)
> - dmaengine_terminate_all(adc->dma_chan);
> err_clr_trig:
> stm32_adc_set_trig(indio_dev, NULL);
> err_pm_put:
> @@ -1568,20 +1561,30 @@ static int stm32_adc_buffer_postenable(struct iio_dev
> *indio_dev)
> return ret;
> }
>
> -static int stm32_adc_buffer_predisable(struct iio_dev *indio_dev)
> +static int stm32_adc_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + int ret;
> +
> + ret = iio_triggered_buffer_postenable(indio_dev);
> + if (ret < 0)
> + return ret;
> +
> + ret = __stm32_adc_buffer_postenable(indio_dev);
> + if (ret < 0)
> + iio_triggered_buffer_predisable(indio_dev);
> +
> + return ret;
> +}
> +
> +static void __stm32_adc_buffer_predisable(struct iio_dev *indio_dev)
> {
> struct stm32_adc *adc = iio_priv(indio_dev);
> struct device *dev = indio_dev->dev.parent;
> - int ret;
>
> adc->cfg->stop_conv(adc);
> if (!adc->dma_chan)
> stm32_adc_conv_irq_disable(adc);
>
> - ret = iio_triggered_buffer_predisable(indio_dev);
> - if (ret < 0)
> - dev_err(_dev->dev, "predisable failed\n");
> -
> if (adc->dma_chan)
> dmaengine_terminate_all(adc->dma_chan);
>
> @@ -1590,6 +1593,17 @@ static int stm32_adc_buffer_predisable(struct iio_dev
> *indio_dev)
>
> pm_runtime_mark_last_busy(dev);
> pm_runtime_put_autosuspend(dev);
> +}
> +
> +static int stm32_adc_buffer_predisable(struct iio_dev *indio_dev)
> +{
> + int ret;
> +
> + __stm32_adc_buffer_predisable(indio_dev);
> +
> + ret = iio_triggered_buffer_predisable(indio_dev);
> + if (ret < 0)
> + dev_err(_dev->dev, "predisable failed\n");
>
> return ret;
> }
> @@ -2013,6 +2027,40 @@ static int stm32_adc_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +#if defined(CONFIG_PM_SLEEP)
> +static int stm32_adc_suspend(struct device *dev)
> +{
> + struct stm32_adc *adc = dev_get_drvdata(dev);
> + struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> +
> + if (iio_buffer_enabled(indio_dev))
> + __stm32_adc_buffer_predisable(indio_dev);
> +
> + return pm_runtime_force_suspend(dev);
> +}
> +
> +static int stm32_adc_resume(struct device *dev)
> +{
> + struct stm32_adc *adc = dev_get_drvdata(dev);
> + struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> + int ret;
> +
> + ret = pm_runtime_force_resume(dev);
> + if (ret < 0)
> + return ret;
> +
> + if (!iio_buffer_enabled(indio_dev))
> + return 0;
> +
> + ret = stm32_adc_update_scan_mode(indio_dev,
> + indio_dev->active_scan_mask);
> + if (ret < 0)
> + return ret;
> +
> + return __stm32_adc_buffer_postenable(indio_dev);
> +}
> +#endif
> +
> #if defined(CONFIG_PM)
> static int stm32_adc_runtime_suspend(struct device *dev)
> {
> @@ -2026,8 +2074,7 @@ static int stm32_adc_runtime_resume(struct device *dev)
> #endif
>
> static const struct dev_pm_ops stm32_adc_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> - pm_runtime_force_resume)
> + SET_SYSTEM_SLEEP_PM_OPS(stm32_adc_suspend, stm32_adc_resume)
> SET_RUNTIME_PM_OPS(stm32_adc_runtime_suspend,
Re: [PATCH 3/3] iio: adc: stm32-adc: switch off running adc when going to low power
On Tue, 20 Nov 2018 11:12:32 +0100
Fabrice Gasnier wrote:
> Switch off ADC when going to low power mode, in case it has been left
> running in buffer mode. Then re-enable it when resuming.
>
> Signed-off-by: Fabrice Gasnier
My suspicion is that we have other drivers not correctly handing this
case, but as far as I can see you have it well covered here.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc.c | 79
> -
> 1 file changed, 63 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index 32c9c61..2a9891c 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -1518,7 +1518,7 @@ static int stm32_adc_dma_start(struct iio_dev
> *indio_dev)
> return 0;
> }
>
> -static int stm32_adc_buffer_postenable(struct iio_dev *indio_dev)
> +static int __stm32_adc_buffer_postenable(struct iio_dev *indio_dev)
> {
> struct stm32_adc *adc = iio_priv(indio_dev);
> struct device *dev = indio_dev->dev.parent;
> @@ -1542,10 +1542,6 @@ static int stm32_adc_buffer_postenable(struct iio_dev
> *indio_dev)
> goto err_clr_trig;
> }
>
> - ret = iio_triggered_buffer_postenable(indio_dev);
> - if (ret < 0)
> - goto err_stop_dma;
> -
> /* Reset adc buffer index */
> adc->bufi = 0;
>
> @@ -1556,9 +1552,6 @@ static int stm32_adc_buffer_postenable(struct iio_dev
> *indio_dev)
>
> return 0;
>
> -err_stop_dma:
> - if (adc->dma_chan)
> - dmaengine_terminate_all(adc->dma_chan);
> err_clr_trig:
> stm32_adc_set_trig(indio_dev, NULL);
> err_pm_put:
> @@ -1568,20 +1561,30 @@ static int stm32_adc_buffer_postenable(struct iio_dev
> *indio_dev)
> return ret;
> }
>
> -static int stm32_adc_buffer_predisable(struct iio_dev *indio_dev)
> +static int stm32_adc_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + int ret;
> +
> + ret = iio_triggered_buffer_postenable(indio_dev);
> + if (ret < 0)
> + return ret;
> +
> + ret = __stm32_adc_buffer_postenable(indio_dev);
> + if (ret < 0)
> + iio_triggered_buffer_predisable(indio_dev);
> +
> + return ret;
> +}
> +
> +static void __stm32_adc_buffer_predisable(struct iio_dev *indio_dev)
> {
> struct stm32_adc *adc = iio_priv(indio_dev);
> struct device *dev = indio_dev->dev.parent;
> - int ret;
>
> adc->cfg->stop_conv(adc);
> if (!adc->dma_chan)
> stm32_adc_conv_irq_disable(adc);
>
> - ret = iio_triggered_buffer_predisable(indio_dev);
> - if (ret < 0)
> - dev_err(_dev->dev, "predisable failed\n");
> -
> if (adc->dma_chan)
> dmaengine_terminate_all(adc->dma_chan);
>
> @@ -1590,6 +1593,17 @@ static int stm32_adc_buffer_predisable(struct iio_dev
> *indio_dev)
>
> pm_runtime_mark_last_busy(dev);
> pm_runtime_put_autosuspend(dev);
> +}
> +
> +static int stm32_adc_buffer_predisable(struct iio_dev *indio_dev)
> +{
> + int ret;
> +
> + __stm32_adc_buffer_predisable(indio_dev);
> +
> + ret = iio_triggered_buffer_predisable(indio_dev);
> + if (ret < 0)
> + dev_err(_dev->dev, "predisable failed\n");
>
> return ret;
> }
> @@ -2013,6 +2027,40 @@ static int stm32_adc_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +#if defined(CONFIG_PM_SLEEP)
> +static int stm32_adc_suspend(struct device *dev)
> +{
> + struct stm32_adc *adc = dev_get_drvdata(dev);
> + struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> +
> + if (iio_buffer_enabled(indio_dev))
> + __stm32_adc_buffer_predisable(indio_dev);
> +
> + return pm_runtime_force_suspend(dev);
> +}
> +
> +static int stm32_adc_resume(struct device *dev)
> +{
> + struct stm32_adc *adc = dev_get_drvdata(dev);
> + struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> + int ret;
> +
> + ret = pm_runtime_force_resume(dev);
> + if (ret < 0)
> + return ret;
> +
> + if (!iio_buffer_enabled(indio_dev))
> + return 0;
> +
> + ret = stm32_adc_update_scan_mode(indio_dev,
> + indio_dev->active_scan_mask);
> + if (ret < 0)
> + return ret;
> +
> + return __stm32_adc_buffer_postenable(indio_dev);
> +}
> +#endif
> +
> #if defined(CONFIG_PM)
> static int stm32_adc_runtime_suspend(struct device *dev)
> {
> @@ -2026,8 +2074,7 @@ static int stm32_adc_runtime_resume(struct device *dev)
> #endif
>
> static const struct dev_pm_ops stm32_adc_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> - pm_runtime_force_resume)
> + SET_SYSTEM_SLEEP_PM_OPS(stm32_adc_suspend, stm32_adc_resume)
> SET_RUNTIME_PM_OPS(stm32_adc_runtime_suspend,
Re: [PATCH 2/3] iio: adc: stm32-adc: add power management support
On Tue, 20 Nov 2018 11:12:31 +0100
Fabrice Gasnier wrote:
> Add support for runtime PM & sleep. Move all regulator and clock management
> to dedicated HW start/stop routines. Then rely on (runtime) PM OPS to
> call them.
>
> Signed-off-by: Fabrice Gasnier
Whilst I'll be the first to admit that runtime pm in particular
gives me a headache everytime I try to review a patch with it in, this
looks good to me.
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc-core.c | 182
> +++
> drivers/iio/adc/stm32-adc.c | 169
> 2 files changed, 258 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc-core.c
> b/drivers/iio/adc/stm32-adc-core.c
> index ca432e7..2327ec1 100644
> --- a/drivers/iio/adc/stm32-adc-core.c
> +++ b/drivers/iio/adc/stm32-adc-core.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -48,15 +49,19 @@
> #define STM32H7_CKMODE_SHIFT 16
> #define STM32H7_CKMODE_MASK GENMASK(17, 16)
>
> +#define STM32_ADC_CORE_SLEEP_DELAY_MS2000
> +
> /**
> * stm32_adc_common_regs - stm32 common registers, compatible dependent data
> * @csr: common status register offset
> + * @ccr: common control register offset
> * @eoc1:adc1 end of conversion flag in @csr
> * @eoc2:adc2 end of conversion flag in @csr
> * @eoc3:adc3 end of conversion flag in @csr
> */
> struct stm32_adc_common_regs {
> u32 csr;
> + u32 ccr;
> u32 eoc1_msk;
> u32 eoc2_msk;
> u32 eoc3_msk;
> @@ -85,6 +90,7 @@ struct stm32_adc_priv_cfg {
> * @vref:regulator reference
> * @cfg: compatible configuration data
> * @common: common data for all ADC instances
> + * @ccr_bak: backup CCR in low power mode
> */
> struct stm32_adc_priv {
> int irq[STM32_ADC_MAX_ADCS];
> @@ -94,6 +100,7 @@ struct stm32_adc_priv {
> struct regulator*vref;
> const struct stm32_adc_priv_cfg *cfg;
> struct stm32_adc_common common;
> + u32 ccr_bak;
> };
>
> static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
> @@ -265,6 +272,7 @@ static int stm32h7_adc_clk_sel(struct platform_device
> *pdev,
> /* STM32F4 common registers definitions */
> static const struct stm32_adc_common_regs stm32f4_adc_common_regs = {
> .csr = STM32F4_ADC_CSR,
> + .ccr = STM32F4_ADC_CCR,
> .eoc1_msk = STM32F4_EOC1,
> .eoc2_msk = STM32F4_EOC2,
> .eoc3_msk = STM32F4_EOC3,
> @@ -273,6 +281,7 @@ static int stm32h7_adc_clk_sel(struct platform_device
> *pdev,
> /* STM32H7 common registers definitions */
> static const struct stm32_adc_common_regs stm32h7_adc_common_regs = {
> .csr = STM32H7_ADC_CSR,
> + .ccr = STM32H7_ADC_CCR,
> .eoc1_msk = STM32H7_EOC_MST,
> .eoc2_msk = STM32H7_EOC_SLV,
> };
> @@ -379,6 +388,61 @@ static void stm32_adc_irq_remove(struct platform_device
> *pdev,
> }
> }
>
> +static int stm32_adc_core_hw_start(struct device *dev)
> +{
> + struct stm32_adc_common *common = dev_get_drvdata(dev);
> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
> + int ret;
> +
> + ret = regulator_enable(priv->vref);
> + if (ret < 0) {
> + dev_err(dev, "vref enable failed\n");
> + return ret;
> + }
> +
> + if (priv->bclk) {
> + ret = clk_prepare_enable(priv->bclk);
> + if (ret < 0) {
> + dev_err(dev, "bus clk enable failed\n");
> + goto err_regulator_disable;
> + }
> + }
> +
> + if (priv->aclk) {
> + ret = clk_prepare_enable(priv->aclk);
> + if (ret < 0) {
> + dev_err(dev, "adc clk enable failed\n");
> + goto err_bclk_disable;
> + }
> + }
> +
> + writel_relaxed(priv->ccr_bak, priv->common.base + priv->cfg->regs->ccr);
> +
> + return 0;
> +
> +err_bclk_disable:
> + if (priv->bclk)
> + clk_disable_unprepare(priv->bclk);
> +err_regulator_disable:
> + regulator_disable(priv->vref);
> +
> + return ret;
> +}
> +
> +static void stm32_adc_core_hw_stop(struct device *dev)
> +{
> + struct stm32_adc_common *common = dev_get_drvdata(dev);
> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
> +
> + /* Backup CCR that may be lost (depends on power state to achieve) */
> + priv->ccr_bak = readl_relaxed(priv->common.base + priv->cfg->regs->ccr);
> + if (priv->aclk)
> + clk_disable_unprepare(priv->aclk);
> + if (priv->bclk)
> + clk_disable_unprepare(priv->bclk);
> + regulator_disable(priv->vref);
> +}
> +
> static int
Re: [PATCH 2/3] iio: adc: stm32-adc: add power management support
On Tue, 20 Nov 2018 11:12:31 +0100
Fabrice Gasnier wrote:
> Add support for runtime PM & sleep. Move all regulator and clock management
> to dedicated HW start/stop routines. Then rely on (runtime) PM OPS to
> call them.
>
> Signed-off-by: Fabrice Gasnier
Whilst I'll be the first to admit that runtime pm in particular
gives me a headache everytime I try to review a patch with it in, this
looks good to me.
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc-core.c | 182
> +++
> drivers/iio/adc/stm32-adc.c | 169
> 2 files changed, 258 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc-core.c
> b/drivers/iio/adc/stm32-adc-core.c
> index ca432e7..2327ec1 100644
> --- a/drivers/iio/adc/stm32-adc-core.c
> +++ b/drivers/iio/adc/stm32-adc-core.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -48,15 +49,19 @@
> #define STM32H7_CKMODE_SHIFT 16
> #define STM32H7_CKMODE_MASK GENMASK(17, 16)
>
> +#define STM32_ADC_CORE_SLEEP_DELAY_MS2000
> +
> /**
> * stm32_adc_common_regs - stm32 common registers, compatible dependent data
> * @csr: common status register offset
> + * @ccr: common control register offset
> * @eoc1:adc1 end of conversion flag in @csr
> * @eoc2:adc2 end of conversion flag in @csr
> * @eoc3:adc3 end of conversion flag in @csr
> */
> struct stm32_adc_common_regs {
> u32 csr;
> + u32 ccr;
> u32 eoc1_msk;
> u32 eoc2_msk;
> u32 eoc3_msk;
> @@ -85,6 +90,7 @@ struct stm32_adc_priv_cfg {
> * @vref:regulator reference
> * @cfg: compatible configuration data
> * @common: common data for all ADC instances
> + * @ccr_bak: backup CCR in low power mode
> */
> struct stm32_adc_priv {
> int irq[STM32_ADC_MAX_ADCS];
> @@ -94,6 +100,7 @@ struct stm32_adc_priv {
> struct regulator*vref;
> const struct stm32_adc_priv_cfg *cfg;
> struct stm32_adc_common common;
> + u32 ccr_bak;
> };
>
> static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
> @@ -265,6 +272,7 @@ static int stm32h7_adc_clk_sel(struct platform_device
> *pdev,
> /* STM32F4 common registers definitions */
> static const struct stm32_adc_common_regs stm32f4_adc_common_regs = {
> .csr = STM32F4_ADC_CSR,
> + .ccr = STM32F4_ADC_CCR,
> .eoc1_msk = STM32F4_EOC1,
> .eoc2_msk = STM32F4_EOC2,
> .eoc3_msk = STM32F4_EOC3,
> @@ -273,6 +281,7 @@ static int stm32h7_adc_clk_sel(struct platform_device
> *pdev,
> /* STM32H7 common registers definitions */
> static const struct stm32_adc_common_regs stm32h7_adc_common_regs = {
> .csr = STM32H7_ADC_CSR,
> + .ccr = STM32H7_ADC_CCR,
> .eoc1_msk = STM32H7_EOC_MST,
> .eoc2_msk = STM32H7_EOC_SLV,
> };
> @@ -379,6 +388,61 @@ static void stm32_adc_irq_remove(struct platform_device
> *pdev,
> }
> }
>
> +static int stm32_adc_core_hw_start(struct device *dev)
> +{
> + struct stm32_adc_common *common = dev_get_drvdata(dev);
> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
> + int ret;
> +
> + ret = regulator_enable(priv->vref);
> + if (ret < 0) {
> + dev_err(dev, "vref enable failed\n");
> + return ret;
> + }
> +
> + if (priv->bclk) {
> + ret = clk_prepare_enable(priv->bclk);
> + if (ret < 0) {
> + dev_err(dev, "bus clk enable failed\n");
> + goto err_regulator_disable;
> + }
> + }
> +
> + if (priv->aclk) {
> + ret = clk_prepare_enable(priv->aclk);
> + if (ret < 0) {
> + dev_err(dev, "adc clk enable failed\n");
> + goto err_bclk_disable;
> + }
> + }
> +
> + writel_relaxed(priv->ccr_bak, priv->common.base + priv->cfg->regs->ccr);
> +
> + return 0;
> +
> +err_bclk_disable:
> + if (priv->bclk)
> + clk_disable_unprepare(priv->bclk);
> +err_regulator_disable:
> + regulator_disable(priv->vref);
> +
> + return ret;
> +}
> +
> +static void stm32_adc_core_hw_stop(struct device *dev)
> +{
> + struct stm32_adc_common *common = dev_get_drvdata(dev);
> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
> +
> + /* Backup CCR that may be lost (depends on power state to achieve) */
> + priv->ccr_bak = readl_relaxed(priv->common.base + priv->cfg->regs->ccr);
> + if (priv->aclk)
> + clk_disable_unprepare(priv->aclk);
> + if (priv->bclk)
> + clk_disable_unprepare(priv->bclk);
> + regulator_disable(priv->vref);
> +}
> +
> static int
Re: [PATCH 1/3] iio: adc: stm32-adc: move self-calibration to prepare routine
On Sun, 25 Nov 2018 13:03:39 +
Jonathan Cameron wrote:
> On Tue, 20 Nov 2018 11:12:30 +0100
> Fabrice Gasnier wrote:
>
> > Move self-calibration routine to prepare routine.
> > - This is precursor patch to ease power management handling.
> > - This also allow to factorize few error cases (error handling).
> >
> > Signed-off-by: Fabrice Gasnier
> one trivial point inline. Otherwise seems a sensible bit of refactoring.
Given this was the only 'issue' I found in the whole set I've
just applied it with that changed.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/adc/stm32-adc.c | 59
> > ++---
> > 1 file changed, 24 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> > index 3784118..dca8733 100644
> > --- a/drivers/iio/adc/stm32-adc.c
> > +++ b/drivers/iio/adc/stm32-adc.c
> > @@ -199,11 +199,13 @@ struct stm32_adc_trig_info {
> > * @calfact_s: Calibration offset for single ended channels
> > * @calfact_d: Calibration offset in differential
> > * @lincalfact: Linearity calibration factor
> > + * @calibrated: Indicates calibration status
> > */
> > struct stm32_adc_calib {
> > u32 calfact_s;
> > u32 calfact_d;
> > u32 lincalfact[STM32H7_LINCALFACT_NUM];
> > + boolcalibrated;
> > };
> >
> > /**
> > @@ -251,7 +253,6 @@ struct stm32_adc_regspec {
> > * @trigs: external trigger sources
> > * @clk_required: clock is required
> > * @has_vregready: vregready status flag presence
> > - * @selfcalib: optional routine for self-calibration
> > * @prepare: optional prepare routine (power-up, enable)
> > * @start_conv:routine to start conversions
> > * @stop_conv: routine to stop conversions
> > @@ -264,7 +265,6 @@ struct stm32_adc_cfg {
> > struct stm32_adc_trig_info *trigs;
> > bool clk_required;
> > bool has_vregready;
> > - int (*selfcalib)(struct stm32_adc *);
> > int (*prepare)(struct stm32_adc *);
> > void (*start_conv)(struct stm32_adc *, bool dma);
> > void (*stop_conv)(struct stm32_adc *);
> > @@ -777,6 +777,7 @@ static void stm32h7_adc_disable(struct stm32_adc *adc)
> > /**
> > * stm32h7_adc_read_selfcalib() - read calibration shadow regs, save result
> > * @adc: stm32 adc instance
> > + * Note: Must be called once ADC is enabled, so LINCALRDYW[1..6] are
> > writable
> > */
> > static int stm32h7_adc_read_selfcalib(struct stm32_adc *adc)
> > {
> > @@ -784,11 +785,6 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> > *adc)
> > int i, ret;
> > u32 lincalrdyw_mask, val;
> >
> > - /* Enable adc so LINCALRDYW1..6 bits are writable */
> > - ret = stm32h7_adc_enable(adc);
> > - if (ret)
> > - return ret;
> > -
> > /* Read linearity calibration */
> > lincalrdyw_mask = STM32H7_LINCALRDYW6;
> > for (i = STM32H7_LINCALFACT_NUM - 1; i >= 0; i--) {
> > @@ -801,7 +797,7 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> > *adc)
> >100, STM32_ADC_TIMEOUT_US);
> > if (ret) {
> > dev_err(_dev->dev, "Failed to read calfact\n");
> > - goto disable;
> > + return ret;
> > }
> >
> > val = stm32_adc_readl(adc, STM32H7_ADC_CALFACT2);
> > @@ -817,11 +813,9 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> > *adc)
> > adc->cal.calfact_s >>= STM32H7_CALFACT_S_SHIFT;
> > adc->cal.calfact_d = (val & STM32H7_CALFACT_D_MASK);
> > adc->cal.calfact_d >>= STM32H7_CALFACT_D_SHIFT;
> > + adc->cal.calibrated = true;
> >
> > -disable:
> > - stm32h7_adc_disable(adc);
> > -
> > - return ret;
> > + return 0;
> > }
> >
> > /**
> > @@ -898,9 +892,9 @@ static int stm32h7_adc_restore_selfcalib(struct
> > stm32_adc *adc)
> > #define STM32H7_ADC_CALIB_TIMEOUT_US 10
> >
> > /**
> > - * stm32h7_adc_selfcalib() - Procedure to calibrate ADC (from power down)
> > + * stm32h7_adc_selfcalib() - Procedure to calibrate ADC
> > * @adc: stm32 adc instance
> > - * Exit from power down, calibrate ADC, then return to power down.
> > + * Note: Must be called once ADC is out of power down.
> > */
> > static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> > {
> > @@ -908,9 +902,8 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> > int ret;
> > u32 val;
> >
> > - ret = stm32h7_adc_exit_pwr_down(adc);
> > - if (ret)
> > - return ret;
> > + if (adc->cal.calibrated)
> > + return adc->cal.calibrated;
> return true seems more logical given this is a boolean.
>
> >
> > /*
> > * Select calibration
Re: [PATCH 1/3] iio: adc: stm32-adc: move self-calibration to prepare routine
On Sun, 25 Nov 2018 13:03:39 +
Jonathan Cameron wrote:
> On Tue, 20 Nov 2018 11:12:30 +0100
> Fabrice Gasnier wrote:
>
> > Move self-calibration routine to prepare routine.
> > - This is precursor patch to ease power management handling.
> > - This also allow to factorize few error cases (error handling).
> >
> > Signed-off-by: Fabrice Gasnier
> one trivial point inline. Otherwise seems a sensible bit of refactoring.
Given this was the only 'issue' I found in the whole set I've
just applied it with that changed.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/adc/stm32-adc.c | 59
> > ++---
> > 1 file changed, 24 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> > index 3784118..dca8733 100644
> > --- a/drivers/iio/adc/stm32-adc.c
> > +++ b/drivers/iio/adc/stm32-adc.c
> > @@ -199,11 +199,13 @@ struct stm32_adc_trig_info {
> > * @calfact_s: Calibration offset for single ended channels
> > * @calfact_d: Calibration offset in differential
> > * @lincalfact: Linearity calibration factor
> > + * @calibrated: Indicates calibration status
> > */
> > struct stm32_adc_calib {
> > u32 calfact_s;
> > u32 calfact_d;
> > u32 lincalfact[STM32H7_LINCALFACT_NUM];
> > + boolcalibrated;
> > };
> >
> > /**
> > @@ -251,7 +253,6 @@ struct stm32_adc_regspec {
> > * @trigs: external trigger sources
> > * @clk_required: clock is required
> > * @has_vregready: vregready status flag presence
> > - * @selfcalib: optional routine for self-calibration
> > * @prepare: optional prepare routine (power-up, enable)
> > * @start_conv:routine to start conversions
> > * @stop_conv: routine to stop conversions
> > @@ -264,7 +265,6 @@ struct stm32_adc_cfg {
> > struct stm32_adc_trig_info *trigs;
> > bool clk_required;
> > bool has_vregready;
> > - int (*selfcalib)(struct stm32_adc *);
> > int (*prepare)(struct stm32_adc *);
> > void (*start_conv)(struct stm32_adc *, bool dma);
> > void (*stop_conv)(struct stm32_adc *);
> > @@ -777,6 +777,7 @@ static void stm32h7_adc_disable(struct stm32_adc *adc)
> > /**
> > * stm32h7_adc_read_selfcalib() - read calibration shadow regs, save result
> > * @adc: stm32 adc instance
> > + * Note: Must be called once ADC is enabled, so LINCALRDYW[1..6] are
> > writable
> > */
> > static int stm32h7_adc_read_selfcalib(struct stm32_adc *adc)
> > {
> > @@ -784,11 +785,6 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> > *adc)
> > int i, ret;
> > u32 lincalrdyw_mask, val;
> >
> > - /* Enable adc so LINCALRDYW1..6 bits are writable */
> > - ret = stm32h7_adc_enable(adc);
> > - if (ret)
> > - return ret;
> > -
> > /* Read linearity calibration */
> > lincalrdyw_mask = STM32H7_LINCALRDYW6;
> > for (i = STM32H7_LINCALFACT_NUM - 1; i >= 0; i--) {
> > @@ -801,7 +797,7 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> > *adc)
> >100, STM32_ADC_TIMEOUT_US);
> > if (ret) {
> > dev_err(_dev->dev, "Failed to read calfact\n");
> > - goto disable;
> > + return ret;
> > }
> >
> > val = stm32_adc_readl(adc, STM32H7_ADC_CALFACT2);
> > @@ -817,11 +813,9 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> > *adc)
> > adc->cal.calfact_s >>= STM32H7_CALFACT_S_SHIFT;
> > adc->cal.calfact_d = (val & STM32H7_CALFACT_D_MASK);
> > adc->cal.calfact_d >>= STM32H7_CALFACT_D_SHIFT;
> > + adc->cal.calibrated = true;
> >
> > -disable:
> > - stm32h7_adc_disable(adc);
> > -
> > - return ret;
> > + return 0;
> > }
> >
> > /**
> > @@ -898,9 +892,9 @@ static int stm32h7_adc_restore_selfcalib(struct
> > stm32_adc *adc)
> > #define STM32H7_ADC_CALIB_TIMEOUT_US 10
> >
> > /**
> > - * stm32h7_adc_selfcalib() - Procedure to calibrate ADC (from power down)
> > + * stm32h7_adc_selfcalib() - Procedure to calibrate ADC
> > * @adc: stm32 adc instance
> > - * Exit from power down, calibrate ADC, then return to power down.
> > + * Note: Must be called once ADC is out of power down.
> > */
> > static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> > {
> > @@ -908,9 +902,8 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> > int ret;
> > u32 val;
> >
> > - ret = stm32h7_adc_exit_pwr_down(adc);
> > - if (ret)
> > - return ret;
> > + if (adc->cal.calibrated)
> > + return adc->cal.calibrated;
> return true seems more logical given this is a boolean.
>
> >
> > /*
> > * Select calibration
Re: WARNING in sysfs_remove_group (2)
On 2018/11/25 20:21, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit: e195ca6cb6f2 Merge branch 'for-linus' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1659a62b40 > kernel config: https://syzkaller.appspot.com/x/.config?x=73e2bc0cb6463446 > dashboard link: https://syzkaller.appspot.com/bug?extid=34cbd0f790e5ab87f63b > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14dad1f540 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1211db8340 C reproducer is essentially same with below one. #syz dup: WARNING in kernfs_get
Re: WARNING in sysfs_remove_group (2)
On 2018/11/25 20:21, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit: e195ca6cb6f2 Merge branch 'for-linus' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1659a62b40 > kernel config: https://syzkaller.appspot.com/x/.config?x=73e2bc0cb6463446 > dashboard link: https://syzkaller.appspot.com/bug?extid=34cbd0f790e5ab87f63b > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14dad1f540 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1211db8340 C reproducer is essentially same with below one. #syz dup: WARNING in kernfs_get
Re: [PATCH 1/3] iio: adc: stm32-adc: move self-calibration to prepare routine
On Tue, 20 Nov 2018 11:12:30 +0100
Fabrice Gasnier wrote:
> Move self-calibration routine to prepare routine.
> - This is precursor patch to ease power management handling.
> - This also allow to factorize few error cases (error handling).
>
> Signed-off-by: Fabrice Gasnier
one trivial point inline. Otherwise seems a sensible bit of refactoring.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc.c | 59
> ++---
> 1 file changed, 24 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index 3784118..dca8733 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -199,11 +199,13 @@ struct stm32_adc_trig_info {
> * @calfact_s: Calibration offset for single ended channels
> * @calfact_d: Calibration offset in differential
> * @lincalfact: Linearity calibration factor
> + * @calibrated: Indicates calibration status
> */
> struct stm32_adc_calib {
> u32 calfact_s;
> u32 calfact_d;
> u32 lincalfact[STM32H7_LINCALFACT_NUM];
> + boolcalibrated;
> };
>
> /**
> @@ -251,7 +253,6 @@ struct stm32_adc_regspec {
> * @trigs: external trigger sources
> * @clk_required:clock is required
> * @has_vregready: vregready status flag presence
> - * @selfcalib: optional routine for self-calibration
> * @prepare: optional prepare routine (power-up, enable)
> * @start_conv: routine to start conversions
> * @stop_conv: routine to stop conversions
> @@ -264,7 +265,6 @@ struct stm32_adc_cfg {
> struct stm32_adc_trig_info *trigs;
> bool clk_required;
> bool has_vregready;
> - int (*selfcalib)(struct stm32_adc *);
> int (*prepare)(struct stm32_adc *);
> void (*start_conv)(struct stm32_adc *, bool dma);
> void (*stop_conv)(struct stm32_adc *);
> @@ -777,6 +777,7 @@ static void stm32h7_adc_disable(struct stm32_adc *adc)
> /**
> * stm32h7_adc_read_selfcalib() - read calibration shadow regs, save result
> * @adc: stm32 adc instance
> + * Note: Must be called once ADC is enabled, so LINCALRDYW[1..6] are writable
> */
> static int stm32h7_adc_read_selfcalib(struct stm32_adc *adc)
> {
> @@ -784,11 +785,6 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> *adc)
> int i, ret;
> u32 lincalrdyw_mask, val;
>
> - /* Enable adc so LINCALRDYW1..6 bits are writable */
> - ret = stm32h7_adc_enable(adc);
> - if (ret)
> - return ret;
> -
> /* Read linearity calibration */
> lincalrdyw_mask = STM32H7_LINCALRDYW6;
> for (i = STM32H7_LINCALFACT_NUM - 1; i >= 0; i--) {
> @@ -801,7 +797,7 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> *adc)
> 100, STM32_ADC_TIMEOUT_US);
> if (ret) {
> dev_err(_dev->dev, "Failed to read calfact\n");
> - goto disable;
> + return ret;
> }
>
> val = stm32_adc_readl(adc, STM32H7_ADC_CALFACT2);
> @@ -817,11 +813,9 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> *adc)
> adc->cal.calfact_s >>= STM32H7_CALFACT_S_SHIFT;
> adc->cal.calfact_d = (val & STM32H7_CALFACT_D_MASK);
> adc->cal.calfact_d >>= STM32H7_CALFACT_D_SHIFT;
> + adc->cal.calibrated = true;
>
> -disable:
> - stm32h7_adc_disable(adc);
> -
> - return ret;
> + return 0;
> }
>
> /**
> @@ -898,9 +892,9 @@ static int stm32h7_adc_restore_selfcalib(struct stm32_adc
> *adc)
> #define STM32H7_ADC_CALIB_TIMEOUT_US 10
>
> /**
> - * stm32h7_adc_selfcalib() - Procedure to calibrate ADC (from power down)
> + * stm32h7_adc_selfcalib() - Procedure to calibrate ADC
> * @adc: stm32 adc instance
> - * Exit from power down, calibrate ADC, then return to power down.
> + * Note: Must be called once ADC is out of power down.
> */
> static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> {
> @@ -908,9 +902,8 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> int ret;
> u32 val;
>
> - ret = stm32h7_adc_exit_pwr_down(adc);
> - if (ret)
> - return ret;
> + if (adc->cal.calibrated)
> + return adc->cal.calibrated;
return true seems more logical given this is a boolean.
>
> /*
>* Select calibration mode:
> @@ -927,7 +920,7 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> STM32H7_ADC_CALIB_TIMEOUT_US);
> if (ret) {
> dev_err(_dev->dev, "calibration failed\n");
> - goto pwr_dwn;
> + goto out;
> }
>
> /*
> @@ -944,18 +937,13 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
>
Re: [PATCH 1/3] iio: adc: stm32-adc: move self-calibration to prepare routine
On Tue, 20 Nov 2018 11:12:30 +0100
Fabrice Gasnier wrote:
> Move self-calibration routine to prepare routine.
> - This is precursor patch to ease power management handling.
> - This also allow to factorize few error cases (error handling).
>
> Signed-off-by: Fabrice Gasnier
one trivial point inline. Otherwise seems a sensible bit of refactoring.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc.c | 59
> ++---
> 1 file changed, 24 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index 3784118..dca8733 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -199,11 +199,13 @@ struct stm32_adc_trig_info {
> * @calfact_s: Calibration offset for single ended channels
> * @calfact_d: Calibration offset in differential
> * @lincalfact: Linearity calibration factor
> + * @calibrated: Indicates calibration status
> */
> struct stm32_adc_calib {
> u32 calfact_s;
> u32 calfact_d;
> u32 lincalfact[STM32H7_LINCALFACT_NUM];
> + boolcalibrated;
> };
>
> /**
> @@ -251,7 +253,6 @@ struct stm32_adc_regspec {
> * @trigs: external trigger sources
> * @clk_required:clock is required
> * @has_vregready: vregready status flag presence
> - * @selfcalib: optional routine for self-calibration
> * @prepare: optional prepare routine (power-up, enable)
> * @start_conv: routine to start conversions
> * @stop_conv: routine to stop conversions
> @@ -264,7 +265,6 @@ struct stm32_adc_cfg {
> struct stm32_adc_trig_info *trigs;
> bool clk_required;
> bool has_vregready;
> - int (*selfcalib)(struct stm32_adc *);
> int (*prepare)(struct stm32_adc *);
> void (*start_conv)(struct stm32_adc *, bool dma);
> void (*stop_conv)(struct stm32_adc *);
> @@ -777,6 +777,7 @@ static void stm32h7_adc_disable(struct stm32_adc *adc)
> /**
> * stm32h7_adc_read_selfcalib() - read calibration shadow regs, save result
> * @adc: stm32 adc instance
> + * Note: Must be called once ADC is enabled, so LINCALRDYW[1..6] are writable
> */
> static int stm32h7_adc_read_selfcalib(struct stm32_adc *adc)
> {
> @@ -784,11 +785,6 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> *adc)
> int i, ret;
> u32 lincalrdyw_mask, val;
>
> - /* Enable adc so LINCALRDYW1..6 bits are writable */
> - ret = stm32h7_adc_enable(adc);
> - if (ret)
> - return ret;
> -
> /* Read linearity calibration */
> lincalrdyw_mask = STM32H7_LINCALRDYW6;
> for (i = STM32H7_LINCALFACT_NUM - 1; i >= 0; i--) {
> @@ -801,7 +797,7 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> *adc)
> 100, STM32_ADC_TIMEOUT_US);
> if (ret) {
> dev_err(_dev->dev, "Failed to read calfact\n");
> - goto disable;
> + return ret;
> }
>
> val = stm32_adc_readl(adc, STM32H7_ADC_CALFACT2);
> @@ -817,11 +813,9 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> *adc)
> adc->cal.calfact_s >>= STM32H7_CALFACT_S_SHIFT;
> adc->cal.calfact_d = (val & STM32H7_CALFACT_D_MASK);
> adc->cal.calfact_d >>= STM32H7_CALFACT_D_SHIFT;
> + adc->cal.calibrated = true;
>
> -disable:
> - stm32h7_adc_disable(adc);
> -
> - return ret;
> + return 0;
> }
>
> /**
> @@ -898,9 +892,9 @@ static int stm32h7_adc_restore_selfcalib(struct stm32_adc
> *adc)
> #define STM32H7_ADC_CALIB_TIMEOUT_US 10
>
> /**
> - * stm32h7_adc_selfcalib() - Procedure to calibrate ADC (from power down)
> + * stm32h7_adc_selfcalib() - Procedure to calibrate ADC
> * @adc: stm32 adc instance
> - * Exit from power down, calibrate ADC, then return to power down.
> + * Note: Must be called once ADC is out of power down.
> */
> static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> {
> @@ -908,9 +902,8 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> int ret;
> u32 val;
>
> - ret = stm32h7_adc_exit_pwr_down(adc);
> - if (ret)
> - return ret;
> + if (adc->cal.calibrated)
> + return adc->cal.calibrated;
return true seems more logical given this is a boolean.
>
> /*
>* Select calibration mode:
> @@ -927,7 +920,7 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> STM32H7_ADC_CALIB_TIMEOUT_US);
> if (ret) {
> dev_err(_dev->dev, "calibration failed\n");
> - goto pwr_dwn;
> + goto out;
> }
>
> /*
> @@ -944,18 +937,13 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
>
