Re: [PATCH 26/34] Documentation/RCU: Use CONFIG_PREEMPTION where appropriate
On 2019-10-15 21:13:30 [-0700], Paul E. McKenney wrote: > Sadly, this one ran afoul of the .txt-to-.rst migration. Even applying > it against linus/master and cherry-picking it does not help. I will > defer it for the moment -- perhaps Mauro or Joel have some advice. Don't worry about it then. Just point me to the tree once it is done. > Thanx, Paul Sebastian
[PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
Kernel Concurrency Sanitizer (KCSAN) is a dynamic data-race detector for kernel space. KCSAN is a sampling watchpoint-based data-race detector. See the included Documentation/dev-tools/kcsan.rst for more details. This patch adds basic infrastructure, but does not yet enable KCSAN for any architecture. Signed-off-by: Marco Elver --- Documentation/dev-tools/kcsan.rst | 202 + MAINTAINERS | 11 + Makefile | 3 +- include/linux/compiler-clang.h| 9 + include/linux/compiler-gcc.h | 7 + include/linux/compiler.h | 35 ++- include/linux/kcsan-checks.h | 116 include/linux/kcsan.h | 85 ++ include/linux/sched.h | 7 + init/init_task.c | 6 + init/main.c | 2 + kernel/Makefile | 1 + kernel/kcsan/Makefile | 14 + kernel/kcsan/atomic.c | 21 ++ kernel/kcsan/core.c | 458 ++ kernel/kcsan/debugfs.c| 225 +++ kernel/kcsan/encoding.h | 94 ++ kernel/kcsan/kcsan.c | 81 ++ kernel/kcsan/kcsan.h | 140 + kernel/kcsan/report.c | 307 kernel/kcsan/test.c | 117 lib/Kconfig.debug | 2 + lib/Kconfig.kcsan | 88 ++ lib/Makefile | 3 + scripts/Makefile.kcsan| 6 + scripts/Makefile.lib | 10 + 26 files changed, 2041 insertions(+), 9 deletions(-) create mode 100644 Documentation/dev-tools/kcsan.rst create mode 100644 include/linux/kcsan-checks.h create mode 100644 include/linux/kcsan.h create mode 100644 kernel/kcsan/Makefile create mode 100644 kernel/kcsan/atomic.c create mode 100644 kernel/kcsan/core.c create mode 100644 kernel/kcsan/debugfs.c create mode 100644 kernel/kcsan/encoding.h create mode 100644 kernel/kcsan/kcsan.c create mode 100644 kernel/kcsan/kcsan.h create mode 100644 kernel/kcsan/report.c create mode 100644 kernel/kcsan/test.c create mode 100644 lib/Kconfig.kcsan create mode 100644 scripts/Makefile.kcsan diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst new file mode 100644 index ..5b46cc5593c3 --- /dev/null +++ b/Documentation/dev-tools/kcsan.rst @@ -0,0 +1,202 @@ +The Kernel Concurrency Sanitizer (KCSAN) + + +Overview + + +*Kernel Concurrency Sanitizer (KCSAN)* is a dynamic data-race detector for +kernel space. KCSAN is a sampling watchpoint-based data-race detector -- this +is unlike Kernel Thread Sanitizer (KTSAN), which is a happens-before data-race +detector. Key priorities in KCSAN's design are lack of false positives, +scalability, and simplicity. More details can be found in `Implementation +Details`_. + +KCSAN uses compile-time instrumentation to instrument memory accesses. KCSAN is +supported in both GCC and Clang. With GCC it requires version 7.3.0 or later. +With Clang it requires version 7.0.0 or later. + +Usage +- + +To enable KCSAN configure kernel with:: + +CONFIG_KCSAN = y + +KCSAN provides several other configuration options to customize behaviour (see +their respective help text for more info). + +debugfs +~~~ + +* The file ``/sys/kernel/debug/kcsan`` can be read to get stats. + +* KCSAN can be turned on or off by writing ``on`` or ``off`` to + ``/sys/kernel/debug/kcsan``. + +* Writing ``!some_func_name`` to ``/sys/kernel/debug/kcsan`` adds + ``some_func_name`` to the report filter list, which (by default) blacklists + reporting data-races where either one of the top stackframes are a function + in the list. + +* Writing either ``blacklist`` or ``whitelist`` to ``/sys/kernel/debug/kcsan`` + changes the report filtering behaviour. For example, the blacklist feature + can be used to silence frequently occurring data-races; the whitelist feature + can help with reproduction and testing of fixes. + +Error reports +~ + +A typical data-race report looks like this:: + +== +BUG: KCSAN: data-race in generic_permission / kernfs_refresh_inode + +write to 0x8fee4c40700c of 4 bytes by task 175 on cpu 4: + kernfs_refresh_inode+0x70/0x170 + kernfs_iop_permission+0x4f/0x90 + inode_permission+0x190/0x200 + link_path_walk.part.0+0x503/0x8e0 + path_lookupat.isra.0+0x69/0x4d0 + filename_lookup+0x136/0x280 + user_path_at_empty+0x47/0x60 + vfs_statx+0x9b/0x130 + __do_sys_newlstat+0x50/0xb0 + __x64_sys_newlstat+0x37/0x50 + do_syscall_64+0x85/0x260 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +read to 0x8fee4c40700c of 4 bytes by task 166 on cpu 6: + generic_permission+0x5b/0x2a0 + kernfs_iop_permission+0x66/0x90 + inode_permission+0x190/0x200 + link_
[PATCH 2/8] objtool, kcsan: Add KCSAN runtime functions to whitelist
This patch adds KCSAN runtime functions to the objtool whitelist.
Signed-off-by: Marco Elver
---
tools/objtool/check.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 044c9a3cb247..d1acc867b43c 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -466,6 +466,23 @@ static const char *uaccess_safe_builtin[] = {
"__asan_report_store4_noabort",
"__asan_report_store8_noabort",
"__asan_report_store16_noabort",
+ /* KCSAN */
+ "__kcsan_check_watchpoint",
+ "__kcsan_setup_watchpoint",
+ /* KCSAN/TSAN out-of-line */
+ "__tsan_func_entry",
+ "__tsan_func_exit",
+ "__tsan_read_range",
+ "__tsan_read1",
+ "__tsan_read2",
+ "__tsan_read4",
+ "__tsan_read8",
+ "__tsan_read16",
+ "__tsan_write1",
+ "__tsan_write2",
+ "__tsan_write4",
+ "__tsan_write8",
+ "__tsan_write16",
/* KCOV */
"write_comp_data",
"__sanitizer_cov_trace_pc",
--
2.23.0.700.g56cf767bdb-goog
[PATCH 0/8] Add Kernel Concurrency Sanitizer (KCSAN)
This is the patch-series for the Kernel Concurrency Sanitizer (KCSAN). KCSAN is a sampling watchpoint-based data-race detector. More details are included in Documentation/dev-tools/kcsan.rst. This patch-series only enables KCSAN for x86, but we expect adding support for other architectures is relatively straightforward (we are aware of experimental ARM64 and POWER support). To gather early feedback, we announced KCSAN back in September, and have integrated the feedback where possible: http://lkml.kernel.org/r/canpmjnpj_bhjflzcapv23axffipiyxxqqu72n6tgwzb2gnu...@mail.gmail.com We want to point out and acknowledge the work surrounding the LKMM, including several articles that motivate why data-races are dangerous [1, 2], justifying a data-race detector such as KCSAN. [1] https://lwn.net/Articles/793253/ [2] https://lwn.net/Articles/799218/ The current list of known upstream fixes for data-races found by KCSAN can be found here: https://github.com/google/ktsan/wiki/KCSAN#upstream-fixes-of-data-races-found-by-kcsan Marco Elver (8): kcsan: Add Kernel Concurrency Sanitizer infrastructure objtool, kcsan: Add KCSAN runtime functions to whitelist build, kcsan: Add KCSAN build exceptions seqlock, kcsan: Add annotations for KCSAN seqlock: Require WRITE_ONCE surrounding raw_seqcount_barrier asm-generic, kcsan: Add KCSAN instrumentation for bitops locking/atomics, kcsan: Add KCSAN instrumentation x86, kcsan: Enable KCSAN for x86 Documentation/dev-tools/kcsan.rst | 202 ++ MAINTAINERS | 11 + Makefile | 3 +- arch/x86/Kconfig | 1 + arch/x86/boot/Makefile| 1 + arch/x86/boot/compressed/Makefile | 1 + arch/x86/entry/vdso/Makefile | 1 + arch/x86/include/asm/bitops.h | 2 +- arch/x86/kernel/Makefile | 6 + arch/x86/kernel/cpu/Makefile | 3 + arch/x86/lib/Makefile | 2 + arch/x86/mm/Makefile | 3 + arch/x86/purgatory/Makefile | 1 + arch/x86/realmode/Makefile| 1 + arch/x86/realmode/rm/Makefile | 1 + drivers/firmware/efi/libstub/Makefile | 1 + include/asm-generic/atomic-instrumented.h | 192 - include/asm-generic/bitops-instrumented.h | 18 + include/linux/compiler-clang.h| 9 + include/linux/compiler-gcc.h | 7 + include/linux/compiler.h | 35 +- include/linux/kcsan-checks.h | 116 ++ include/linux/kcsan.h | 85 include/linux/sched.h | 7 + include/linux/seqlock.h | 51 ++- init/init_task.c | 6 + init/main.c | 2 + kernel/Makefile | 6 + kernel/kcsan/Makefile | 14 + kernel/kcsan/atomic.c | 21 + kernel/kcsan/core.c | 458 ++ kernel/kcsan/debugfs.c| 225 +++ kernel/kcsan/encoding.h | 94 + kernel/kcsan/kcsan.c | 81 kernel/kcsan/kcsan.h | 140 +++ kernel/kcsan/report.c | 307 +++ kernel/kcsan/test.c | 117 ++ kernel/sched/Makefile | 6 + lib/Kconfig.debug | 2 + lib/Kconfig.kcsan | 88 + lib/Makefile | 3 + mm/Makefile | 8 + scripts/Makefile.kcsan| 6 + scripts/Makefile.lib | 10 + scripts/atomic/gen-atomic-instrumented.sh | 9 +- tools/objtool/check.c | 17 + 46 files changed, 2364 insertions(+), 16 deletions(-) create mode 100644 Documentation/dev-tools/kcsan.rst create mode 100644 include/linux/kcsan-checks.h create mode 100644 include/linux/kcsan.h create mode 100644 kernel/kcsan/Makefile create mode 100644 kernel/kcsan/atomic.c create mode 100644 kernel/kcsan/core.c create mode 100644 kernel/kcsan/debugfs.c create mode 100644 kernel/kcsan/encoding.h create mode 100644 kernel/kcsan/kcsan.c create mode 100644 kernel/kcsan/kcsan.h create mode 100644 kernel/kcsan/report.c create mode 100644 kernel/kcsan/test.c create mode 100644 lib/Kconfig.kcsan create mode 100644 scripts/Makefile.kcsan -- 2.23.0.700.g56cf767bdb-goog
[PATCH 3/8] build, kcsan: Add KCSAN build exceptions
This blacklists several compilation units from KCSAN. See the respective
inline comments for the reasoning.
Signed-off-by: Marco Elver
---
kernel/Makefile | 5 +
kernel/sched/Makefile | 6 ++
mm/Makefile | 8
3 files changed, 19 insertions(+)
diff --git a/kernel/Makefile b/kernel/Makefile
index 74ab46e2ebd1..4a597a68b8bc 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -23,6 +23,9 @@ endif
# Prevents flicker of uninteresting __do_softirq()/__local_bh_disable_ip()
# in coverage traces.
KCOV_INSTRUMENT_softirq.o := n
+# Avoid KCSAN instrumentation in softirq ("No shared variables, all the data
+# are CPU local" => assume no data-races), to reduce overhead in interrupts.
+KCSAN_SANITIZE_softirq.o = n
# These are called from save_stack_trace() on slub debug path,
# and produce insane amounts of uninteresting coverage.
KCOV_INSTRUMENT_module.o := n
@@ -30,6 +33,7 @@ KCOV_INSTRUMENT_extable.o := n
# Don't self-instrument.
KCOV_INSTRUMENT_kcov.o := n
KASAN_SANITIZE_kcov.o := n
+KCSAN_SANITIZE_kcov.o := n
CFLAGS_kcov.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
# cond_syscall is currently not LTO compatible
@@ -118,6 +122,7 @@ obj-$(CONFIG_RSEQ) += rseq.o
obj-$(CONFIG_GCC_PLUGIN_STACKLEAK) += stackleak.o
KASAN_SANITIZE_stackleak.o := n
+KCSAN_SANITIZE_stackleak.o := n
KCOV_INSTRUMENT_stackleak.o := n
$(obj)/configs.o: $(obj)/config_data.gz
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index 21fb5a5662b5..e9307a9c54e7 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -7,6 +7,12 @@ endif
# that is not a function of syscall inputs. E.g. involuntary context switches.
KCOV_INSTRUMENT := n
+# There are numerous races here, however, most of them due to plain accesses.
+# This would make it even harder for syzbot to find reproducers, because these
+# bugs trigger without specific input. Disable by default, but should re-enable
+# eventually.
+KCSAN_SANITIZE := n
+
ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
# According to Alan Modra , the -fno-omit-frame-pointer
is
# needed for x86 only. Why this used to be enabled for all architectures is
beyond
diff --git a/mm/Makefile b/mm/Makefile
index d996846697ef..33ea0154dd2d 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -7,6 +7,14 @@ KASAN_SANITIZE_slab_common.o := n
KASAN_SANITIZE_slab.o := n
KASAN_SANITIZE_slub.o := n
+# These produce frequent data-race reports: most of them are due to races on
+# the same word but accesses to different bits of that word. Re-enable KCSAN
+# for these when we have more consensus on what to do about them.
+KCSAN_SANITIZE_slab_common.o := n
+KCSAN_SANITIZE_slab.o := n
+KCSAN_SANITIZE_slub.o := n
+KCSAN_SANITIZE_page_alloc.o := n
+
# These files are disabled because they produce non-interesting and/or
# flaky coverage that is not a function of syscall inputs. E.g. slab is out of
# free pages, or a task is migrated between nodes.
--
2.23.0.700.g56cf767bdb-goog
[PATCH 4/8] seqlock, kcsan: Add annotations for KCSAN
Since seqlocks in the Linux kernel do not require the use of marked
atomic accesses in critical sections, we teach KCSAN to assume such
accesses are atomic. KCSAN currently also pretends that writes to
`sequence` are atomic, although currently plain writes are used (their
corresponding reads are READ_ONCE).
Further, to avoid false positives in the absence of clear ending of a
seqlock reader critical section (only when using the raw interface),
KCSAN assumes a fixed number of accesses after start of a seqlock
critical section are atomic.
Signed-off-by: Marco Elver
---
include/linux/seqlock.h | 44 +
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index bcf4cf26b8c8..1e425831a7ed 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -37,8 +37,24 @@
#include
#include
#include
+#include
#include
+/*
+ * The seqlock interface does not prescribe a precise sequence of read
+ * begin/retry/end. For readers, typically there is a call to
+ * read_seqcount_begin() and read_seqcount_retry(), however, there are more
+ * esoteric cases which do not follow this pattern.
+ *
+ * As a consequence, we take the following best-effort approach for *raw* usage
+ * of seqlocks under KCSAN: upon beginning a seq-reader critical section,
+ * pessimistically mark then next KCSAN_SEQLOCK_REGION_MAX memory accesses as
+ * atomics; if there is a matching read_seqcount_retry() call, no following
+ * memory operations are considered atomic. Non-raw usage of seqlocks is not
+ * affected.
+ */
+#define KCSAN_SEQLOCK_REGION_MAX 1000
+
/*
* Version using sequence counter only.
* This can be used when code has its own mutex protecting the
@@ -115,6 +131,7 @@ static inline unsigned __read_seqcount_begin(const
seqcount_t *s)
cpu_relax();
goto repeat;
}
+ kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX);
return ret;
}
@@ -131,6 +148,7 @@ static inline unsigned raw_read_seqcount(const seqcount_t
*s)
{
unsigned ret = READ_ONCE(s->sequence);
smp_rmb();
+ kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX);
return ret;
}
@@ -183,6 +201,7 @@ static inline unsigned raw_seqcount_begin(const seqcount_t
*s)
{
unsigned ret = READ_ONCE(s->sequence);
smp_rmb();
+ kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX);
return ret & ~1;
}
@@ -202,7 +221,8 @@ static inline unsigned raw_seqcount_begin(const seqcount_t
*s)
*/
static inline int __read_seqcount_retry(const seqcount_t *s, unsigned start)
{
- return unlikely(s->sequence != start);
+ kcsan_atomic_next(0);
+ return unlikely(READ_ONCE(s->sequence) != start);
}
/**
@@ -225,6 +245,7 @@ static inline int read_seqcount_retry(const seqcount_t *s,
unsigned start)
static inline void raw_write_seqcount_begin(seqcount_t *s)
{
+ kcsan_begin_atomic(true);
s->sequence++;
smp_wmb();
}
@@ -233,6 +254,7 @@ static inline void raw_write_seqcount_end(seqcount_t *s)
{
smp_wmb();
s->sequence++;
+ kcsan_end_atomic(true);
}
/**
@@ -262,18 +284,20 @@ static inline void raw_write_seqcount_end(seqcount_t *s)
*
* void write(void)
* {
- * Y = true;
+ * WRITE_ONCE(Y, true);
*
* raw_write_seqcount_barrier(seq);
*
- * X = false;
+ * WRITE_ONCE(X, false);
* }
*/
static inline void raw_write_seqcount_barrier(seqcount_t *s)
{
+ kcsan_begin_atomic(true);
s->sequence++;
smp_wmb();
s->sequence++;
+ kcsan_end_atomic(true);
}
static inline int raw_read_seqcount_latch(seqcount_t *s)
@@ -398,7 +422,9 @@ static inline void write_seqcount_end(seqcount_t *s)
static inline void write_seqcount_invalidate(seqcount_t *s)
{
smp_wmb();
+ kcsan_begin_atomic(true);
s->sequence+=2;
+ kcsan_end_atomic(true);
}
typedef struct {
@@ -430,11 +456,21 @@ typedef struct {
*/
static inline unsigned read_seqbegin(const seqlock_t *sl)
{
- return read_seqcount_begin(&sl->seqcount);
+ unsigned ret = read_seqcount_begin(&sl->seqcount);
+
+ kcsan_atomic_next(0); /* non-raw usage, assume closing read_seqretry */
+ kcsan_begin_atomic(false);
+ return ret;
}
static inline unsigned read_seqretry(const seqlock_t *sl, unsigned start)
{
+ /*
+* Assume not nested: read_seqretry may be called multiple times when
+* completing read critical section.
+*/
+ kcsan_end_atomic(false);
+
return read_seqcount_retry(&sl->seqcount, start);
}
--
2.23.0.700.g56cf767bdb-goog
[PATCH 5/8] seqlock: Require WRITE_ONCE surrounding raw_seqcount_barrier
This patch proposes to require marked atomic accesses surrounding raw_write_seqcount_barrier. We reason that otherwise there is no way to guarantee propagation nor atomicity of writes before/after the barrier [1]. For example, consider the compiler tears stores either before or after the barrier; in this case, readers may observe a partial value, and because readers are unaware that writes are going on (writes are not in a seq-writer critical section), will complete the seq-reader critical section while having observed some partial state. [1] https://lwn.net/Articles/793253/ This came up when designing and implementing KCSAN, because KCSAN would flag these accesses as data-races. After careful analysis, our reasoning as above led us to conclude that the best thing to do is to propose an amendment to the raw_seqcount_barrier usage. Signed-off-by: Marco Elver --- include/linux/seqlock.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h index 1e425831a7ed..5d50aad53b47 100644 --- a/include/linux/seqlock.h +++ b/include/linux/seqlock.h @@ -265,6 +265,13 @@ static inline void raw_write_seqcount_end(seqcount_t *s) * usual consistency guarantee. It is one wmb cheaper, because we can * collapse the two back-to-back wmb()s. * + * Note that, writes surrounding the barrier should be declared atomic (e.g. + * via WRITE_ONCE): a) to ensure the writes become visible to other threads + * atomically, avoiding compiler optimizations; b) to document which writes are + * meant to propagate to the reader critical section. This is necessary because + * neither writes before and after the barrier are enclosed in a seq-writer + * critical section that would ensure readers are aware of ongoing writes. + * * seqcount_t seq; * bool X = true, Y = false; * -- 2.23.0.700.g56cf767bdb-goog
[PATCH 7/8] locking/atomics, kcsan: Add KCSAN instrumentation
This adds KCSAN instrumentation to atomic-instrumented.h.
Signed-off-by: Marco Elver
---
include/asm-generic/atomic-instrumented.h | 192 +-
scripts/atomic/gen-atomic-instrumented.sh | 9 +-
2 files changed, 199 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/atomic-instrumented.h
b/include/asm-generic/atomic-instrumented.h
index e8730c6b9fe2..9e487febc610 100644
--- a/include/asm-generic/atomic-instrumented.h
+++ b/include/asm-generic/atomic-instrumented.h
@@ -19,11 +19,13 @@
#include
#include
+#include
static inline int
atomic_read(const atomic_t *v)
{
kasan_check_read(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), false);
return arch_atomic_read(v);
}
#define atomic_read atomic_read
@@ -33,6 +35,7 @@ static inline int
atomic_read_acquire(const atomic_t *v)
{
kasan_check_read(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), false);
return arch_atomic_read_acquire(v);
}
#define atomic_read_acquire atomic_read_acquire
@@ -42,6 +45,7 @@ static inline void
atomic_set(atomic_t *v, int i)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
arch_atomic_set(v, i);
}
#define atomic_set atomic_set
@@ -51,6 +55,7 @@ static inline void
atomic_set_release(atomic_t *v, int i)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
arch_atomic_set_release(v, i);
}
#define atomic_set_release atomic_set_release
@@ -60,6 +65,7 @@ static inline void
atomic_add(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
arch_atomic_add(i, v);
}
#define atomic_add atomic_add
@@ -69,6 +75,7 @@ static inline int
atomic_add_return(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_add_return(i, v);
}
#define atomic_add_return atomic_add_return
@@ -79,6 +86,7 @@ static inline int
atomic_add_return_acquire(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_add_return_acquire(i, v);
}
#define atomic_add_return_acquire atomic_add_return_acquire
@@ -89,6 +97,7 @@ static inline int
atomic_add_return_release(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_add_return_release(i, v);
}
#define atomic_add_return_release atomic_add_return_release
@@ -99,6 +108,7 @@ static inline int
atomic_add_return_relaxed(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_add_return_relaxed(i, v);
}
#define atomic_add_return_relaxed atomic_add_return_relaxed
@@ -109,6 +119,7 @@ static inline int
atomic_fetch_add(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_fetch_add(i, v);
}
#define atomic_fetch_add atomic_fetch_add
@@ -119,6 +130,7 @@ static inline int
atomic_fetch_add_acquire(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_fetch_add_acquire(i, v);
}
#define atomic_fetch_add_acquire atomic_fetch_add_acquire
@@ -129,6 +141,7 @@ static inline int
atomic_fetch_add_release(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_fetch_add_release(i, v);
}
#define atomic_fetch_add_release atomic_fetch_add_release
@@ -139,6 +152,7 @@ static inline int
atomic_fetch_add_relaxed(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_fetch_add_relaxed(i, v);
}
#define atomic_fetch_add_relaxed atomic_fetch_add_relaxed
@@ -148,6 +162,7 @@ static inline void
atomic_sub(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
arch_atomic_sub(i, v);
}
#define atomic_sub atomic_sub
@@ -157,6 +172,7 @@ static inline int
atomic_sub_return(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_sub_return(i, v);
}
#define atomic_sub_return atomic_sub_return
@@ -167,6 +183,7 @@ static inline int
atomic_sub_return_acquire(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*v), true);
return arch_atomic_sub_return_acquire(i, v);
}
#define atomic_sub_return_acquire atomic_sub_return_acquire
@@ -177,6 +194,7 @@ static inline int
atomic_sub_return_release(int i, atomic_t *v)
{
kasan_check_write(v, sizeof(*v));
+ kcsan_check_atomic(v, sizeof(*
[PATCH 8/8] x86, kcsan: Enable KCSAN for x86
This patch enables KCSAN for x86, with updates to build rules to not use
KCSAN for several incompatible compilation units.
Signed-off-by: Marco Elver
---
arch/x86/Kconfig | 1 +
arch/x86/boot/Makefile| 1 +
arch/x86/boot/compressed/Makefile | 1 +
arch/x86/entry/vdso/Makefile | 1 +
arch/x86/include/asm/bitops.h | 2 +-
arch/x86/kernel/Makefile | 6 ++
arch/x86/kernel/cpu/Makefile | 3 +++
arch/x86/lib/Makefile | 2 ++
arch/x86/mm/Makefile | 3 +++
arch/x86/purgatory/Makefile | 1 +
arch/x86/realmode/Makefile| 1 +
arch/x86/realmode/rm/Makefile | 1 +
drivers/firmware/efi/libstub/Makefile | 1 +
13 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d6e1faa28c58..81859be4a005 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -226,6 +226,7 @@ config X86
select VIRT_TO_BUS
select X86_FEATURE_NAMESif PROC_FS
select PROC_PID_ARCH_STATUS if PROC_FS
+ select HAVE_ARCH_KCSAN if X86_64
config INSTRUCTION_DECODER
def_bool y
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index e2839b5c246c..2f9e928acae6 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -10,6 +10,7 @@
#
KASAN_SANITIZE := n
+KCSAN_SANITIZE := n
OBJECT_FILES_NON_STANDARD := y
# Kernel does not boot with kcov instrumentation here.
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index 6b84afdd7538..0921689f7c70 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -18,6 +18,7 @@
# compressed vmlinux.bin.all + u32 size of vmlinux.bin.all
KASAN_SANITIZE := n
+KCSAN_SANITIZE := n
OBJECT_FILES_NON_STANDARD := y
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 0f2154106d01..d2cd34d2ac4e 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -12,6 +12,7 @@ include $(srctree)/lib/vdso/Makefile
KBUILD_CFLAGS += $(DISABLE_LTO)
KASAN_SANITIZE := n
UBSAN_SANITIZE := n
+KCSAN_SANITIZE := n
OBJECT_FILES_NON_STANDARD := y
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 7d1f6a49bfae..a36d900960e4 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -201,7 +201,7 @@ arch_test_and_change_bit(long nr, volatile unsigned long
*addr)
return GEN_BINARY_RMWcc(LOCK_PREFIX __ASM_SIZE(btc), *addr, c, "Ir",
nr);
}
-static __always_inline bool constant_test_bit(long nr, const volatile unsigned
long *addr)
+static __no_kcsan_or_inline bool constant_test_bit(long nr, const volatile
unsigned long *addr)
{
return ((1UL << (nr & (BITS_PER_LONG-1))) &
(addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 3578ad248bc9..adccbbfa47e4 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -28,6 +28,12 @@ KASAN_SANITIZE_dumpstack_$(BITS).o := n
KASAN_SANITIZE_stacktrace.o:= n
KASAN_SANITIZE_paravirt.o := n
+KCSAN_SANITIZE_head$(BITS).o := n
+KCSAN_SANITIZE_dumpstack.o := n
+KCSAN_SANITIZE_dumpstack_$(BITS).o := n
+KCSAN_SANITIZE_stacktrace.o:= n
+KCSAN_SANITIZE_paravirt.o := n
+
OBJECT_FILES_NON_STANDARD_relocate_kernel_$(BITS).o:= y
OBJECT_FILES_NON_STANDARD_test_nx.o:= y
OBJECT_FILES_NON_STANDARD_paravirt_patch.o := y
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index d7a1e5a9331c..7651c4f37e5e 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -3,6 +3,9 @@
# Makefile for x86-compatible CPU details, features and quirks
#
+KCSAN_SANITIZE_common.o = n
+KCSAN_SANITIZE_perf_event.o = n
+
# Don't trace early stages of a secondary CPU boot
ifdef CONFIG_FUNCTION_TRACER
CFLAGS_REMOVE_common.o = -pg
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 5246db42de45..4e4b74f525f2 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -5,11 +5,13 @@
# Produces uninteresting flaky coverage.
KCOV_INSTRUMENT_delay.o:= n
+KCSAN_SANITIZE_delay.o := n
# Early boot use of cmdline; don't instrument it
ifdef CONFIG_AMD_MEM_ENCRYPT
KCOV_INSTRUMENT_cmdline.o := n
KASAN_SANITIZE_cmdline.o := n
+KCSAN_SANITIZE_cmdline.o := n
ifdef CONFIG_FUNCTION_TRACER
CFLAGS_REMOVE_cmdl
[PATCH 6/8] asm-generic, kcsan: Add KCSAN instrumentation for bitops
Add explicit KCSAN checks for bitops.
Signed-off-by: Marco Elver
---
include/asm-generic/bitops-instrumented.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/asm-generic/bitops-instrumented.h
b/include/asm-generic/bitops-instrumented.h
index ddd1c6d9d8db..5767debd4b52 100644
--- a/include/asm-generic/bitops-instrumented.h
+++ b/include/asm-generic/bitops-instrumented.h
@@ -12,6 +12,7 @@
#define _ASM_GENERIC_BITOPS_INSTRUMENTED_H
#include
+#include
/**
* set_bit - Atomically set a bit in memory
@@ -26,6 +27,7 @@
static inline void set_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_atomic(addr + BIT_WORD(nr), sizeof(long), true);
arch_set_bit(nr, addr);
}
@@ -41,6 +43,7 @@ static inline void set_bit(long nr, volatile unsigned long
*addr)
static inline void __set_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_access(addr + BIT_WORD(nr), sizeof(long), true);
arch___set_bit(nr, addr);
}
@@ -54,6 +57,7 @@ static inline void __set_bit(long nr, volatile unsigned long
*addr)
static inline void clear_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_atomic(addr + BIT_WORD(nr), sizeof(long), true);
arch_clear_bit(nr, addr);
}
@@ -69,6 +73,7 @@ static inline void clear_bit(long nr, volatile unsigned long
*addr)
static inline void __clear_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_access(addr + BIT_WORD(nr), sizeof(long), true);
arch___clear_bit(nr, addr);
}
@@ -82,6 +87,7 @@ static inline void __clear_bit(long nr, volatile unsigned
long *addr)
static inline void clear_bit_unlock(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_atomic(addr + BIT_WORD(nr), sizeof(long), true);
arch_clear_bit_unlock(nr, addr);
}
@@ -97,6 +103,7 @@ static inline void clear_bit_unlock(long nr, volatile
unsigned long *addr)
static inline void __clear_bit_unlock(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_access(addr + BIT_WORD(nr), sizeof(long), true);
arch___clear_bit_unlock(nr, addr);
}
@@ -113,6 +120,7 @@ static inline void __clear_bit_unlock(long nr, volatile
unsigned long *addr)
static inline void change_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_atomic(addr + BIT_WORD(nr), sizeof(long), true);
arch_change_bit(nr, addr);
}
@@ -128,6 +136,7 @@ static inline void change_bit(long nr, volatile unsigned
long *addr)
static inline void __change_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_access(addr + BIT_WORD(nr), sizeof(long), true);
arch___change_bit(nr, addr);
}
@@ -141,6 +150,7 @@ static inline void __change_bit(long nr, volatile unsigned
long *addr)
static inline bool test_and_set_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_atomic(addr + BIT_WORD(nr), sizeof(long), true);
return arch_test_and_set_bit(nr, addr);
}
@@ -155,6 +165,7 @@ static inline bool test_and_set_bit(long nr, volatile
unsigned long *addr)
static inline bool __test_and_set_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_access(addr + BIT_WORD(nr), sizeof(long), true);
return arch___test_and_set_bit(nr, addr);
}
@@ -170,6 +181,7 @@ static inline bool __test_and_set_bit(long nr, volatile
unsigned long *addr)
static inline bool test_and_set_bit_lock(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_atomic(addr + BIT_WORD(nr), sizeof(long), true);
return arch_test_and_set_bit_lock(nr, addr);
}
@@ -183,6 +195,7 @@ static inline bool test_and_set_bit_lock(long nr, volatile
unsigned long *addr)
static inline bool test_and_clear_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_atomic(addr + BIT_WORD(nr), sizeof(long), true);
return arch_test_and_clear_bit(nr, addr);
}
@@ -197,6 +210,7 @@ static inline bool test_and_clear_bit(long nr, volatile
unsigned long *addr)
static inline bool __test_and_clear_bit(long nr, volatile unsigned long *addr)
{
kasan_check_write(addr + BIT_WORD(nr), sizeof(long));
+ kcsan_check_access(addr + BIT_WORD(nr), sizeof(long), true);
return arch___test_and_clear_bit(nr, addr);
}
@
[PATCH v6 0/2] Add CCPI2 PMU support
Add Cavium Coherent Processor Interconnect (CCPI2) PMU support in ThunderX2 Uncore driver. v6: Rebased to 5.4-rc1 v5: Fixed minor bug of v4 (timer callback fuction was getting initialized to NULL for all PMUs). v4: Update with review comments [2]. Changed Counter read to 2 word read since single dword read is misbhehaving(hw issue). [2] https://lkml.org/lkml/2019/7/23/231 v3: Rebased to 5.3-rc1 v2: Updated with review comments [1] [1] https://lkml.org/lkml/2019/6/14/965 v1: initial patch Ganapatrao Prabhakerrao Kulkarni (2): Documentation: perf: Update documentation for ThunderX2 PMU uncore driver drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver. .../admin-guide/perf/thunderx2-pmu.rst| 20 +- drivers/perf/thunderx2_pmu.c | 267 +++--- 2 files changed, 245 insertions(+), 42 deletions(-) -- 2.17.1
[PATCH v6 2/2] drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
CCPI2 is a low-latency high-bandwidth serial interface for inter socket
connectivity of ThunderX2 processors.
CCPI2 PMU supports up to 8 counters per socket. Counters are
independently programmable to different events and can be started and
stopped individually. The CCPI2 counters are 64-bit and do not overflow
in normal operation.
Signed-off-by: Ganapatrao Prabhakerrao Kulkarni
---
drivers/perf/thunderx2_pmu.c | 267 ++-
1 file changed, 234 insertions(+), 33 deletions(-)
diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
index 43d76c85da56..51b31d6ff2c4 100644
--- a/drivers/perf/thunderx2_pmu.c
+++ b/drivers/perf/thunderx2_pmu.c
@@ -16,23 +16,36 @@
* they need to be sampled before overflow(i.e, at every 2 seconds).
*/
-#define TX2_PMU_MAX_COUNTERS 4
+#define TX2_PMU_DMC_L3C_MAX_COUNTERS 4
+#define TX2_PMU_CCPI2_MAX_COUNTERS 8
+#define TX2_PMU_MAX_COUNTERS TX2_PMU_CCPI2_MAX_COUNTERS
+
+
#define TX2_PMU_DMC_CHANNELS 8
#define TX2_PMU_L3_TILES 16
#define TX2_PMU_HRTIMER_INTERVAL (2 * NSEC_PER_SEC)
-#define GET_EVENTID(ev)((ev->hw.config) & 0x1f)
-#define GET_COUNTERID(ev) ((ev->hw.idx) & 0x3)
+#define GET_EVENTID(ev, mask) ((ev->hw.config) & mask)
+#define GET_COUNTERID(ev, mask)((ev->hw.idx) & mask)
/* 1 byte per counter(4 counters).
* Event id is encoded in bits [5:1] of a byte,
*/
#define DMC_EVENT_CFG(idx, val)((val) << (((idx) * 8) + 1))
+/* bits[3:0] to select counters, are indexed from 8 to 15. */
+#define CCPI2_COUNTER_OFFSET 8
+
#define L3C_COUNTER_CTL0xA8
#define L3C_COUNTER_DATA 0xAC
#define DMC_COUNTER_CTL0x234
#define DMC_COUNTER_DATA 0x240
+#define CCPI2_PERF_CTL 0x108
+#define CCPI2_COUNTER_CTL 0x10C
+#define CCPI2_COUNTER_SEL 0x12c
+#define CCPI2_COUNTER_DATA_L 0x130
+#define CCPI2_COUNTER_DATA_H 0x134
+
/* L3C event IDs */
#define L3_EVENT_READ_REQ 0xD
#define L3_EVENT_WRITEBACK_REQ 0xE
@@ -51,15 +64,28 @@
#define DMC_EVENT_READ_TXNS0xF
#define DMC_EVENT_MAX 0x10
+#define CCPI2_EVENT_REQ_PKT_SENT 0x3D
+#define CCPI2_EVENT_SNOOP_PKT_SENT 0x65
+#define CCPI2_EVENT_DATA_PKT_SENT 0x105
+#define CCPI2_EVENT_GIC_PKT_SENT 0x12D
+#define CCPI2_EVENT_MAX0x200
+
+#define CCPI2_PERF_CTL_ENABLE BIT(0)
+#define CCPI2_PERF_CTL_START BIT(1)
+#define CCPI2_PERF_CTL_RESET BIT(4)
+#define CCPI2_EVENT_LEVEL_RISING_EDGE BIT(10)
+#define CCPI2_EVENT_TYPE_EDGE_SENSITIVEBIT(11)
+
enum tx2_uncore_type {
PMU_TYPE_L3C,
PMU_TYPE_DMC,
+ PMU_TYPE_CCPI2,
PMU_TYPE_INVALID,
};
/*
- * pmu on each socket has 2 uncore devices(dmc and l3c),
- * each device has 4 counters.
+ * Each socket has 3 uncore devices associated with a PMU. The DMC and
+ * L3C have 4 32-bit counters and the CCPI2 has 8 64-bit counters.
*/
struct tx2_uncore_pmu {
struct hlist_node hpnode;
@@ -69,8 +95,10 @@ struct tx2_uncore_pmu {
int node;
int cpu;
u32 max_counters;
+ u32 counters_mask;
u32 prorate_factor;
u32 max_events;
+ u32 events_mask;
u64 hrtimer_interval;
void __iomem *base;
DECLARE_BITMAP(active_counters, TX2_PMU_MAX_COUNTERS);
@@ -79,6 +107,7 @@ struct tx2_uncore_pmu {
struct hrtimer hrtimer;
const struct attribute_group **attr_groups;
enum tx2_uncore_type type;
+ enum hrtimer_restart (*hrtimer_callback)(struct hrtimer *cb);
void (*init_cntr_base)(struct perf_event *event,
struct tx2_uncore_pmu *tx2_pmu);
void (*stop_event)(struct perf_event *event);
@@ -92,7 +121,21 @@ static inline struct tx2_uncore_pmu *pmu_to_tx2_pmu(struct
pmu *pmu)
return container_of(pmu, struct tx2_uncore_pmu, pmu);
}
-PMU_FORMAT_ATTR(event, "config:0-4");
+#define TX2_PMU_FORMAT_ATTR(_var, _name, _format) \
+static ssize_t \
+__tx2_pmu_##_var##_show(struct device *dev,\
+ struct device_attribute *attr, \
+ char *page) \
+{ \
+ BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
+ return sprintf(page, _format "\n"); \
+} \
+ \
+static struct device_attribute format_attr_##_var =\
+ __ATTR(_
[PATCH v6 1/2] Documentation: perf: Update documentation for ThunderX2 PMU uncore driver
Add documentation for Cavium Coherent Processor Interconnect (CCPI2) PMU. Signed-off-by: Ganapatrao Prabhakerrao Kulkarni --- .../admin-guide/perf/thunderx2-pmu.rst| 20 ++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/Documentation/admin-guide/perf/thunderx2-pmu.rst b/Documentation/admin-guide/perf/thunderx2-pmu.rst index 08e33675853a..01f158238ae1 100644 --- a/Documentation/admin-guide/perf/thunderx2-pmu.rst +++ b/Documentation/admin-guide/perf/thunderx2-pmu.rst @@ -3,24 +3,26 @@ Cavium ThunderX2 SoC Performance Monitoring Unit (PMU UNCORE) = The ThunderX2 SoC PMU consists of independent, system-wide, per-socket -PMUs such as the Level 3 Cache (L3C) and DDR4 Memory Controller (DMC). +PMUs such as the Level 3 Cache (L3C), DDR4 Memory Controller (DMC) and +Cavium Coherent Processor Interconnect (CCPI2). The DMC has 8 interleaved channels and the L3C has 16 interleaved tiles. Events are counted for the default channel (i.e. channel 0) and prorated to the total number of channels/tiles. -The DMC and L3C support up to 4 counters. Counters are independently -programmable and can be started and stopped individually. Each counter -can be set to a different event. Counters are 32-bit and do not support -an overflow interrupt; they are read every 2 seconds. +The DMC and L3C support up to 4 counters, while the CCPI2 supports up to 8 +counters. Counters are independently programmable to different events and +can be started and stopped individually. None of the counters support an +overflow interrupt. DMC and L3C counters are 32-bit and read every 2 seconds. +The CCPI2 counters are 64-bit and assumed not to overflow in normal operation. PMU UNCORE (perf) driver: The thunderx2_pmu driver registers per-socket perf PMUs for the DMC and -L3C devices. Each PMU can be used to count up to 4 events -simultaneously. The PMUs provide a description of their available events -and configuration options under sysfs, see -/sys/devices/uncore_; S is the socket id. +L3C devices. Each PMU can be used to count up to 4 (DMC/L3C) or up to 8 +(CCPI2) events simultaneously. The PMUs provide a description of their +available events and configuration options under sysfs, see +/sys/devices/uncore_; S is the socket id. The driver does not support sampling, therefore "perf record" will not work. Per-task perf sessions are also not supported. -- 2.17.1
Re: [PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
Hi Marco,
On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
[...]
> --- /dev/null
> +++ b/kernel/kcsan/kcsan.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * The Kernel Concurrency Sanitizer (KCSAN) infrastructure. For more info
> please
> + * see Documentation/dev-tools/kcsan.rst.
> + */
> +
> +#include
> +
> +#include "kcsan.h"
> +
> +/*
> + * Concurrency Sanitizer uses the same instrumentation as Thread Sanitizer.
Is there any documentation on the instrumentation? Like a complete list
for all instrumentation functions plus a description of where the
compiler will use those functions. Yes, the names of the below functions
are straightforward, but an accurate doc on the instrumentation will
cerntainly help people review KCSAN.
Regards,
Boqun
> + */
> +
> +#define DEFINE_TSAN_READ_WRITE(size)
> \
> + void __tsan_read##size(void *ptr) \
> + { \
> + __kcsan_check_access(ptr, size, false);\
> + } \
> + EXPORT_SYMBOL(__tsan_read##size); \
> + void __tsan_write##size(void *ptr) \
> + { \
> + __kcsan_check_access(ptr, size, true); \
> + } \
> + EXPORT_SYMBOL(__tsan_write##size)
> +
> +DEFINE_TSAN_READ_WRITE(1);
> +DEFINE_TSAN_READ_WRITE(2);
> +DEFINE_TSAN_READ_WRITE(4);
> +DEFINE_TSAN_READ_WRITE(8);
> +DEFINE_TSAN_READ_WRITE(16);
> +
> +/*
> + * Not all supported compiler versions distinguish aligned/unaligned
> accesses,
> + * but e.g. recent versions of Clang do.
> + */
> +#define DEFINE_TSAN_UNALIGNED_READ_WRITE(size)
> \
> + void __tsan_unaligned_read##size(void *ptr)\
> + { \
> + __kcsan_check_access(ptr, size, false);\
> + } \
> + EXPORT_SYMBOL(__tsan_unaligned_read##size);\
> + void __tsan_unaligned_write##size(void *ptr) \
> + { \
> + __kcsan_check_access(ptr, size, true); \
> + } \
> + EXPORT_SYMBOL(__tsan_unaligned_write##size)
> +
> +DEFINE_TSAN_UNALIGNED_READ_WRITE(2);
> +DEFINE_TSAN_UNALIGNED_READ_WRITE(4);
> +DEFINE_TSAN_UNALIGNED_READ_WRITE(8);
> +DEFINE_TSAN_UNALIGNED_READ_WRITE(16);
> +
> +void __tsan_read_range(void *ptr, size_t size)
> +{
> + __kcsan_check_access(ptr, size, false);
> +}
> +EXPORT_SYMBOL(__tsan_read_range);
> +
> +void __tsan_write_range(void *ptr, size_t size)
> +{
> + __kcsan_check_access(ptr, size, true);
> +}
> +EXPORT_SYMBOL(__tsan_write_range);
> +
> +/*
> + * The below are not required KCSAN, but can still be emitted by the
> compiler.
> + */
> +void __tsan_func_entry(void *call_pc)
> +{
> +}
> +EXPORT_SYMBOL(__tsan_func_entry);
> +void __tsan_func_exit(void)
> +{
> +}
> +EXPORT_SYMBOL(__tsan_func_exit);
> +void __tsan_init(void)
> +{
> +}
> +EXPORT_SYMBOL(__tsan_init);
[...]
signature.asc
Description: PGP signature
Re: [PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
On Wed, 16 Oct 2019 at 11:42, Boqun Feng wrote:
>
> Hi Marco,
>
> On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
> [...]
> > --- /dev/null
> > +++ b/kernel/kcsan/kcsan.c
> > @@ -0,0 +1,81 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/*
> > + * The Kernel Concurrency Sanitizer (KCSAN) infrastructure. For more info
> > please
> > + * see Documentation/dev-tools/kcsan.rst.
> > + */
> > +
> > +#include
> > +
> > +#include "kcsan.h"
> > +
> > +/*
> > + * Concurrency Sanitizer uses the same instrumentation as Thread Sanitizer.
>
> Is there any documentation on the instrumentation? Like a complete list
> for all instrumentation functions plus a description of where the
> compiler will use those functions. Yes, the names of the below functions
> are straightforward, but an accurate doc on the instrumentation will
> cerntainly help people review KCSAN.
As far as I'm aware neither GCC nor Clang have documentation on the
emitted instrumentation that we could reference (other than look into
the compiler passes).
However it is as straightforward as it seems: the compiler emits
instrumentation calls for all loads and stores that the compiler
generates; inline asm is not instrumented. I will add a comment to
that effect for v2.
Thanks,
-- Marco
> Regards,
> Boqun
>
> > + */
> > +
> > +#define DEFINE_TSAN_READ_WRITE(size)
> > \
> > + void __tsan_read##size(void *ptr)
> > \
> > + {
> > \
> > + __kcsan_check_access(ptr, size, false);
> > \
> > + }
> > \
> > + EXPORT_SYMBOL(__tsan_read##size);
> > \
> > + void __tsan_write##size(void *ptr)
> > \
> > + {
> > \
> > + __kcsan_check_access(ptr, size, true);
> > \
> > + }
> > \
> > + EXPORT_SYMBOL(__tsan_write##size)
> > +
> > +DEFINE_TSAN_READ_WRITE(1);
> > +DEFINE_TSAN_READ_WRITE(2);
> > +DEFINE_TSAN_READ_WRITE(4);
> > +DEFINE_TSAN_READ_WRITE(8);
> > +DEFINE_TSAN_READ_WRITE(16);
> > +
> > +/*
> > + * Not all supported compiler versions distinguish aligned/unaligned
> > accesses,
> > + * but e.g. recent versions of Clang do.
> > + */
> > +#define DEFINE_TSAN_UNALIGNED_READ_WRITE(size)
> > \
> > + void __tsan_unaligned_read##size(void *ptr)
> > \
> > + {
> > \
> > + __kcsan_check_access(ptr, size, false);
> > \
> > + }
> > \
> > + EXPORT_SYMBOL(__tsan_unaligned_read##size);
> > \
> > + void __tsan_unaligned_write##size(void *ptr)
> > \
> > + {
> > \
> > + __kcsan_check_access(ptr, size, true);
> > \
> > + }
> > \
> > + EXPORT_SYMBOL(__tsan_unaligned_write##size)
> > +
> > +DEFINE_TSAN_UNALIGNED_READ_WRITE(2);
> > +DEFINE_TSAN_UNALIGNED_READ_WRITE(4);
> > +DEFINE_TSAN_UNALIGNED_READ_WRITE(8);
> > +DEFINE_TSAN_UNALIGNED_READ_WRITE(16);
> > +
> > +void __tsan_read_range(void *ptr, size_t size)
> > +{
> > + __kcsan_check_access(ptr, size, false);
> > +}
> > +EXPORT_SYMBOL(__tsan_read_range);
> > +
> > +void __tsan_write_range(void *ptr, size_t size)
> > +{
> > + __kcsan_check_access(ptr, size, true);
> > +}
> > +EXPORT_SYMBOL(__tsan_write_range);
> > +
> > +/*
> > + * The below are not required KCSAN, but can still be emitted by the
> > compiler.
> > + */
> > +void __tsan_func_entry(void *call_pc)
> > +{
> > +}
> > +EXPORT_SYMBOL(__tsan_func_entry);
> > +void __tsan_func_exit(void)
> > +{
> > +}
> > +EXPORT_SYMBOL(__tsan_func_exit);
> > +void __tsan_init(void)
> > +{
> > +}
> > +EXPORT_SYMBOL(__tsan_init);
> [...]
Re: [PATCH v6 3/5] serial: fsl_linflexuart: Be consistent with the name
Hello Greg, On 10/15/2019 10:05 PM, Greg KH wrote: > > This patch does not apply to my tree :( > Thanks for letting me know; I will rebase it in v7. Regards, Stefan
Re: [PATCH 7/8] locking/atomics, kcsan: Add KCSAN instrumentation
Hi Marco,
On Wed, Oct 16, 2019 at 10:39:58AM +0200, Marco Elver wrote:
> This adds KCSAN instrumentation to atomic-instrumented.h.
>
> Signed-off-by: Marco Elver
> ---
> include/asm-generic/atomic-instrumented.h | 192 +-
> scripts/atomic/gen-atomic-instrumented.sh | 9 +-
> 2 files changed, 199 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-generic/atomic-instrumented.h
> b/include/asm-generic/atomic-instrumented.h
> index e8730c6b9fe2..9e487febc610 100644
> --- a/include/asm-generic/atomic-instrumented.h
> +++ b/include/asm-generic/atomic-instrumented.h
> @@ -19,11 +19,13 @@
>
> #include
> #include
> +#include
>
> static inline int
> atomic_read(const atomic_t *v)
> {
> kasan_check_read(v, sizeof(*v));
> + kcsan_check_atomic(v, sizeof(*v), false);
For legibility and consistency with kasan, it would be nicer to avoid
the bool argument here and have kcsan_check_atomic_{read,write}()
helpers...
> diff --git a/scripts/atomic/gen-atomic-instrumented.sh
> b/scripts/atomic/gen-atomic-instrumented.sh
> index e09812372b17..c0553743a6f4 100755
> --- a/scripts/atomic/gen-atomic-instrumented.sh
> +++ b/scripts/atomic/gen-atomic-instrumented.sh
> @@ -12,15 +12,20 @@ gen_param_check()
> local type="${arg%%:*}"
> local name="$(gen_param_name "${arg}")"
> local rw="write"
> + local is_write="true"
>
> case "${type#c}" in
> i) return;;
> esac
>
> # We don't write to constant parameters
> - [ ${type#c} != ${type} ] && rw="read"
> + if [ ${type#c} != ${type} ]; then
> + rw="read"
> + is_write="false"
> + fi
>
> printf "\tkasan_check_${rw}(${name}, sizeof(*${name}));\n"
> + printf "\tkcsan_check_atomic(${name}, sizeof(*${name}), ${is_write});\n"
... which would also simplify this.
Though as below, we might want to wrap both in a helper local to
atomic-instrumented.h.
> }
>
> #gen_param_check(arg...)
> @@ -108,6 +113,7 @@ cat < ({ \\
> typeof(ptr) __ai_ptr = (ptr); \\
> kasan_check_write(__ai_ptr, ${mult}sizeof(*__ai_ptr)); \\
> + kcsan_check_atomic(__ai_ptr, ${mult}sizeof(*__ai_ptr), true); \\
> arch_${xchg}(__ai_ptr, __VA_ARGS__);\\
> })
> EOF
> @@ -148,6 +154,7 @@ cat << EOF
>
> #include
> #include
> +#include
We could add the following to this preamble:
static inline void __atomic_check_read(const volatile void *v, size_t size)
{
kasan_check_read(v, sizeof(*v));
kcsan_check_atomic(v, sizeof(*v), false);
}
static inline void __atomic_check_write(const volatile void *v, size_t size)
{
kasan_check_write(v, sizeof(*v));
kcsan_check_atomic(v, sizeof(*v), true);
}
... and only have the one call in each atomic wrapper.
Otherwise, this looks good to me.
Thanks,
Mark.
Re: [PATCH 7/8] locking/atomics, kcsan: Add KCSAN instrumentation
On Wed, 16 Oct 2019 at 13:18, Mark Rutland wrote:
>
> Hi Marco,
>
> On Wed, Oct 16, 2019 at 10:39:58AM +0200, Marco Elver wrote:
> > This adds KCSAN instrumentation to atomic-instrumented.h.
> >
> > Signed-off-by: Marco Elver
> > ---
> > include/asm-generic/atomic-instrumented.h | 192 +-
> > scripts/atomic/gen-atomic-instrumented.sh | 9 +-
> > 2 files changed, 199 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/asm-generic/atomic-instrumented.h
> > b/include/asm-generic/atomic-instrumented.h
> > index e8730c6b9fe2..9e487febc610 100644
> > --- a/include/asm-generic/atomic-instrumented.h
> > +++ b/include/asm-generic/atomic-instrumented.h
> > @@ -19,11 +19,13 @@
> >
> > #include
> > #include
> > +#include
> >
> > static inline int
> > atomic_read(const atomic_t *v)
> > {
> > kasan_check_read(v, sizeof(*v));
> > + kcsan_check_atomic(v, sizeof(*v), false);
>
> For legibility and consistency with kasan, it would be nicer to avoid
> the bool argument here and have kcsan_check_atomic_{read,write}()
> helpers...
>
> > diff --git a/scripts/atomic/gen-atomic-instrumented.sh
> > b/scripts/atomic/gen-atomic-instrumented.sh
> > index e09812372b17..c0553743a6f4 100755
> > --- a/scripts/atomic/gen-atomic-instrumented.sh
> > +++ b/scripts/atomic/gen-atomic-instrumented.sh
> > @@ -12,15 +12,20 @@ gen_param_check()
> > local type="${arg%%:*}"
> > local name="$(gen_param_name "${arg}")"
> > local rw="write"
> > + local is_write="true"
> >
> > case "${type#c}" in
> > i) return;;
> > esac
> >
> > # We don't write to constant parameters
> > - [ ${type#c} != ${type} ] && rw="read"
> > + if [ ${type#c} != ${type} ]; then
> > + rw="read"
> > + is_write="false"
> > + fi
> >
> > printf "\tkasan_check_${rw}(${name}, sizeof(*${name}));\n"
> > + printf "\tkcsan_check_atomic(${name}, sizeof(*${name}),
> > ${is_write});\n"
>
> ... which would also simplify this.
>
> Though as below, we might want to wrap both in a helper local to
> atomic-instrumented.h.
>
> > }
> >
> > #gen_param_check(arg...)
> > @@ -108,6 +113,7 @@ cat < > ({ \\
> > typeof(ptr) __ai_ptr = (ptr); \\
> > kasan_check_write(__ai_ptr, ${mult}sizeof(*__ai_ptr)); \\
> > + kcsan_check_atomic(__ai_ptr, ${mult}sizeof(*__ai_ptr), true); \\
> > arch_${xchg}(__ai_ptr, __VA_ARGS__);\\
> > })
> > EOF
> > @@ -148,6 +154,7 @@ cat << EOF
> >
> > #include
> > #include
> > +#include
>
> We could add the following to this preamble:
>
> static inline void __atomic_check_read(const volatile void *v, size_t size)
> {
> kasan_check_read(v, sizeof(*v));
> kcsan_check_atomic(v, sizeof(*v), false);
> }
>
> static inline void __atomic_check_write(const volatile void *v, size_t size)
> {
> kasan_check_write(v, sizeof(*v));
> kcsan_check_atomic(v, sizeof(*v), true);
> }
>
> ... and only have the one call in each atomic wrapper.
>
> Otherwise, this looks good to me.
Thanks, incorporated suggestions for v2: for readability rename
kcsan_check_access -> kcsan_check_{read,write}, and for
atomic-instrumented.h, adding the suggested preamble.
Thanks,
-- Marco
Re: [PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
On Wed, Oct 16, 2019 at 10:41 AM Marco Elver wrote: > > Kernel Concurrency Sanitizer (KCSAN) is a dynamic data-race detector for > kernel space. KCSAN is a sampling watchpoint-based data-race detector. > See the included Documentation/dev-tools/kcsan.rst for more details. > > This patch adds basic infrastructure, but does not yet enable KCSAN for > any architecture. > > Signed-off-by: Marco Elver > --- > Documentation/dev-tools/kcsan.rst | 202 + > MAINTAINERS | 11 + > Makefile | 3 +- > include/linux/compiler-clang.h| 9 + > include/linux/compiler-gcc.h | 7 + > include/linux/compiler.h | 35 ++- > include/linux/kcsan-checks.h | 116 > include/linux/kcsan.h | 85 ++ > include/linux/sched.h | 7 + > init/init_task.c | 6 + > init/main.c | 2 + > kernel/Makefile | 1 + > kernel/kcsan/Makefile | 14 + > kernel/kcsan/atomic.c | 21 ++ > kernel/kcsan/core.c | 458 ++ > kernel/kcsan/debugfs.c| 225 +++ > kernel/kcsan/encoding.h | 94 ++ > kernel/kcsan/kcsan.c | 81 ++ > kernel/kcsan/kcsan.h | 140 + > kernel/kcsan/report.c | 307 > kernel/kcsan/test.c | 117 > lib/Kconfig.debug | 2 + > lib/Kconfig.kcsan | 88 ++ > lib/Makefile | 3 + > scripts/Makefile.kcsan| 6 + > scripts/Makefile.lib | 10 + > 26 files changed, 2041 insertions(+), 9 deletions(-) > create mode 100644 Documentation/dev-tools/kcsan.rst > create mode 100644 include/linux/kcsan-checks.h > create mode 100644 include/linux/kcsan.h > create mode 100644 kernel/kcsan/Makefile > create mode 100644 kernel/kcsan/atomic.c > create mode 100644 kernel/kcsan/core.c > create mode 100644 kernel/kcsan/debugfs.c > create mode 100644 kernel/kcsan/encoding.h > create mode 100644 kernel/kcsan/kcsan.c > create mode 100644 kernel/kcsan/kcsan.h > create mode 100644 kernel/kcsan/report.c > create mode 100644 kernel/kcsan/test.c > create mode 100644 lib/Kconfig.kcsan > create mode 100644 scripts/Makefile.kcsan > > diff --git a/Documentation/dev-tools/kcsan.rst > b/Documentation/dev-tools/kcsan.rst > new file mode 100644 > index ..5b46cc5593c3 > --- /dev/null > +++ b/Documentation/dev-tools/kcsan.rst > @@ -0,0 +1,202 @@ > +The Kernel Concurrency Sanitizer (KCSAN) > + > + > +Overview > + > + > +*Kernel Concurrency Sanitizer (KCSAN)* is a dynamic data-race detector for > +kernel space. KCSAN is a sampling watchpoint-based data-race detector -- this > +is unlike Kernel Thread Sanitizer (KTSAN), which is a happens-before > data-race > +detector. Key priorities in KCSAN's design are lack of false positives, > +scalability, and simplicity. More details can be found in `Implementation > +Details`_. > + > +KCSAN uses compile-time instrumentation to instrument memory accesses. KCSAN > is > +supported in both GCC and Clang. With GCC it requires version 7.3.0 or later. > +With Clang it requires version 7.0.0 or later. > + > +Usage > +- > + > +To enable KCSAN configure kernel with:: > + > +CONFIG_KCSAN = y > + > +KCSAN provides several other configuration options to customize behaviour > (see > +their respective help text for more info). > + > +debugfs > +~~~ > + > +* The file ``/sys/kernel/debug/kcsan`` can be read to get stats. > + > +* KCSAN can be turned on or off by writing ``on`` or ``off`` to > + ``/sys/kernel/debug/kcsan``. > + > +* Writing ``!some_func_name`` to ``/sys/kernel/debug/kcsan`` adds > + ``some_func_name`` to the report filter list, which (by default) blacklists > + reporting data-races where either one of the top stackframes are a function > + in the list. > + > +* Writing either ``blacklist`` or ``whitelist`` to > ``/sys/kernel/debug/kcsan`` > + changes the report filtering behaviour. For example, the blacklist feature > + can be used to silence frequently occurring data-races; the whitelist > feature > + can help with reproduction and testing of fixes. > + > +Error reports > +~ > + > +A typical data-race report looks like this:: > + > +== > +BUG: KCSAN: data-race in generic_permission / kernfs_refresh_inode > + > +write to 0x8fee4c40700c of 4 bytes by task 175 on cpu 4: > + kernfs_refresh_inode+0x70/0x170 > + kernfs_iop_permission+0x4f/0x90 > + inode_permission+0x190/0x200 > + link_path_walk.part.0+0x503/0x8e0 > + path_lookupat.isra.0+0x69/0x4d0 > + filename_lookup+0x136/0x280 > + user_path_at_empty+0x47/0x60 > + vfs_statx+0x9b/0x130 > + __do_sys_newlstat+0
Re: [PATCH v7 0/8] efi/firmware/platform-x86: Add EFI embedded fw support
On Mon, Oct 14, 2019 at 12:57:54PM +0200, Greg Kroah-Hartman wrote: > On Mon, Oct 14, 2019 at 10:31:50AM +, Luis Chamberlain wrote: > > On Mon, Oct 14, 2019 at 11:29:29AM +0200, Greg Kroah-Hartman wrote: > > > On Mon, Oct 14, 2019 at 09:22:16AM +, Luis Chamberlain wrote: > > > > On Fri, Oct 11, 2019 at 06:38:19PM +0200, Greg Kroah-Hartman wrote: > > > > > On Fri, Oct 11, 2019 at 03:38:23PM +, Luis Chamberlain wrote: > > > > > > On Fri, Oct 11, 2019 at 04:31:26PM +0200, Hans de Goede wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On 10/11/19 4:10 PM, Luis Chamberlain wrote: > > > > > > > > Hey Hans, thanks for staying on top of this and follow up! For > > > > > > > > some > > > > > > > > reason the universe conspired against your first and last patch > > > > > > > > ([1/8], > > > > > > > > [8/8]), and I never got them. Could you bounce these or resend > > > > > > > > in case > > > > > > > > others confirm they also didn't get it? > > > > > > > > > > > > > > I have received feedback from others on the first patch, so at > > > > > > > least > > > > > > > that one has reached others. I've bounced patches 1 and 8 to you. > > > > > > > > > > > > Thanks, can you also bounce the feedback received? > > > > > > > > > > That is what lore.kernel.org is for... > > > > > > > > If I have feedback on an email which I did not get I cannot easily > > > > reply to it. > > > > > > I meant, use lore.kernel.org to download the mbox of the thread and then > > > use your email client to respond to whatever you need there. This all > > > is public, no need to ask anyone else to bounce emails to you. > > > > Last I looked it didn't allow you to downlaod an mbox of a thread... > > It can, from the front page of "all" threads, or on the thread itself, > at the bottom of the page. Search for "download" on the page. Sweet! Luis
[PATCH v7 5/5] arm64: defconfig: Enable configs for S32V234
From: Mihaela Martinas Enable support for the S32V234 SoC, including the previously added UART driver. Signed-off-by: Mihaela Martinas Signed-off-by: Adrian.Nitu Signed-off-by: Stoica Cosmin-Stefan Signed-off-by: Stefan-Gabriel Mirea --- arch/arm64/configs/defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index c9a867ac32d4..bc14d95c1665 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -48,6 +48,7 @@ CONFIG_ARCH_MXC=y CONFIG_ARCH_QCOM=y CONFIG_ARCH_RENESAS=y CONFIG_ARCH_ROCKCHIP=y +CONFIG_ARCH_S32=y CONFIG_ARCH_SEATTLE=y CONFIG_ARCH_STRATIX10=y CONFIG_ARCH_SYNQUACER=y @@ -352,6 +353,8 @@ CONFIG_SERIAL_XILINX_PS_UART=y CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y CONFIG_SERIAL_FSL_LPUART=y CONFIG_SERIAL_FSL_LPUART_CONSOLE=y +CONFIG_SERIAL_FSL_LINFLEXUART=y +CONFIG_SERIAL_FSL_LINFLEXUART_CONSOLE=y CONFIG_SERIAL_MVEBU_UART=y CONFIG_SERIAL_DEV_BUS=y CONFIG_VIRTIO_CONSOLE=y -- 2.22.0
[PATCH v7 3/5] serial: fsl_linflexuart: Be consistent with the name
For consistency reasons, spell the controller name as "LINFlexD" in
comments and documentation.
Signed-off-by: Stefan-Gabriel Mirea
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
drivers/tty/serial/Kconfig | 8
drivers/tty/serial/fsl_linflexuart.c| 4 ++--
include/uapi/linux/serial_core.h| 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index a84a83f8881e..6dbd871493af 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1101,7 +1101,7 @@
mapped with the correct attributes.
linflex,
- Use early console provided by Freescale LinFlex UART
+ Use early console provided by Freescale LINFlexD UART
serial driver for NXP S32V234 SoCs. A valid base
address must be provided, and the serial port must
already be setup and configured.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 67a9eb3f94ce..c07c2667a2e4 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1392,19 +1392,19 @@ config SERIAL_FSL_LPUART_CONSOLE
you can make it the console by answering Y to this option.
config SERIAL_FSL_LINFLEXUART
- tristate "Freescale linflexuart serial port support"
+ tristate "Freescale LINFlexD UART serial port support"
depends on PRINTK
select SERIAL_CORE
help
- Support for the on-chip linflexuart on some Freescale SOCs.
+ Support for the on-chip LINFlexD UART on some Freescale SOCs.
config SERIAL_FSL_LINFLEXUART_CONSOLE
- bool "Console on Freescale linflexuart serial port"
+ bool "Console on Freescale LINFlexD UART serial port"
depends on SERIAL_FSL_LINFLEXUART=y
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
help
- If you have enabled the linflexuart serial port on the Freescale
+ If you have enabled the LINFlexD UART serial port on the Freescale
SoCs, you can make it the console by answering Y to this option.
config SERIAL_CONEXANT_DIGICOLOR
diff --git a/drivers/tty/serial/fsl_linflexuart.c
b/drivers/tty/serial/fsl_linflexuart.c
index a32f0d2afd59..205c31a61684 100644
--- a/drivers/tty/serial/fsl_linflexuart.c
+++ b/drivers/tty/serial/fsl_linflexuart.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * Freescale linflexuart serial port driver
+ * Freescale LINFlexD UART serial port driver
*
* Copyright 2012-2016 Freescale Semiconductor, Inc.
* Copyright 2017-2019 NXP
@@ -940,5 +940,5 @@ static void __exit linflex_serial_exit(void)
module_init(linflex_serial_init);
module_exit(linflex_serial_exit);
-MODULE_DESCRIPTION("Freescale linflex serial port driver");
+MODULE_DESCRIPTION("Freescale LINFlexD serial port driver");
MODULE_LICENSE("GPL v2");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index e7fe550b6038..8ec3dd742ea4 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -290,7 +290,7 @@
/* Sunix UART */
#define PORT_SUNIX 121
-/* Freescale Linflex UART */
+/* Freescale LINFlexD UART */
#define PORT_LINFLEXUART 122
#endif /* _UAPILINUX_SERIAL_CORE_H */
--
2.22.0
[PATCH v7 2/5] arm64: Introduce config for S32
From: Mihaela Martinas Add configuration option for the NXP S32 platform family in Kconfig.platforms. For starters, the only SoC supported will be Treerunner (S32V234), with a single execution target: the S32V234-EVB (rev 29288) board. Signed-off-by: Mihaela Martinas Signed-off-by: Stoica Cosmin-Stefan Signed-off-by: Stefan-Gabriel Mirea --- arch/arm64/Kconfig.platforms | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 16d761475a86..17f1c34ec750 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -212,6 +212,11 @@ config ARCH_ROCKCHIP This enables support for the ARMv8 based Rockchip chipsets, like the RK3368. +config ARCH_S32 + bool "NXP S32 SoC Family" + help + This enables support for the NXP S32 family of processors. + config ARCH_SEATTLE bool "AMD Seattle SoC Family" help -- 2.22.0
[PATCH v7 0/5] Add initial support for S32V234-EVB
Hello,
NXP's S32V234[1] ("Treerunner") vision microprocessors are targeted for
high-performance, computationally intensive vision and sensor fusion
applications that require automotive safety levels. They include leading
edge Camera Vision modules like APEX-2, ISP and GPU. The S32V234-EVB and
S32V234-SBC boards are available for customer evaluation.
The following patch series introduces minimal enablement support for the
NXP S32V234-EVB2[2] board, which leverages most of the SoC capabilities.
Up to v2, this series also included the fsl_linflexuart driver, which has
been included in Linux 5.4-rc1[3].
In the future, we aim to submit multiple drivers upstream, which can be
found in the kernel of our Auto Linux BSP[4] ("ALB"), starting with basic
pinmuxing, clock and uSDHC drivers.
For validation, you can use the U-Boot bootloader in the ALB[5], which we
build and test with our patched version of the Linaro GCC 6.3.1 2017.05
toolchain for ARM 64-bit, with sources available on [6].
Changes in v7:
* Rebase the patch 'serial: fsl_linflexuart: Be consistent with the name'
on the tty-next branch in Greg's tty git tree.
Changes in v6:
* In the patch 'serial: fsl_linflexuart: Be consistent with the name',
avoid updating the definition of PORT_LINFLEXUART; that was an
independent fix which has been submitted and accepted[9] separately;
* Avoid using 'base64' as 'Content-Transfer-Encoding'.
Changes in v5:
* Remove the patch 'dt-bindings: serial: Document Freescale LINFlexD UART'
following its acceptance in Linux 5.4-rc1[8];
* Rebase the other patches on v5.4-rc1.
Changes in v4:
* Remove the patch 'serial: fsl_linflexuart: Update compatible string'
following its acceptance[7];
* Rebase the patch 'serial: fsl_linflexuart: Be consistent with the name'
on the tty-next branch in Greg's tty git tree.
Changes in v3:
* Remove the patch 'tty: serial: Add linflexuart driver for S32V234'
following its acceptance[3];
* Replace 'Freescale' with 'NXP' in the ARCH_S32 config definition and the
'model' property from the device tree;
* Remove the 'fsl-' prefixes from the dtsi and dts file names;
* Move the 'model' property from (fsl-)s32v234.dtsi to s32v234-evb.dts;
* Add newlines between the cpu nodes in s32v234.dtsi;
* Make use of GIC_SPI, GIC_PPI, GIC_CPU_MASK_SIMPLE and IRQ_TYPE_* in the
'interrupts' tuples;
* Move the 'timer' and 'interrupt-controller' nodes before 'soc' in
s32v234.dtsi;
* Be consistent with the 'LINFlexD' spelling in documentation, strings and
comments; add new patch 'serial: fsl_linflexuart: Be consistent with the
name' to update the LINFlexD driver as well;
* Remove from fsl,s32-linflexuart.txt a statement regarding the limitation
to UART mode;
* Make the compatible string SoC specific ("fsl,s32v234-linflexuart"); add
new patch 'serial: fsl_linflexuart: Update compatible string' to update
the LINFlexD driver as well;
* In the LINFlexD binding documentation, insert a space between label and
node name and remove the 'status' property.
Changes in v2:
* Update the entry in fsl.yaml to apply to all S32V234 based boards;
* Add chosen node to dts, with a 'stdout-path' property for earlycon;
* Remove linflex_verify_port(), because it was only called from
uart_set_info(), which was going to always fail at the "baud_base < 9600"
check, as we are not using uartclk from uart_port yet;
* Fix compatible string used in OF_EARLYCON_DECLARE.
[1]
https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/s32-automotive-platform/vision-processor-for-front-and-surround-view-camera-machine-learning-and-sensor-fusion:S32V234
[2]
https://www.nxp.com/support/developer-resources/evaluation-and-development-boards/ultra-reliable-dev-platforms/s32v-mpus-platforms/s32v-vision-and-sensor-fusion-evaluation-system:S32V234EVB
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09864c1cdf5c537bd01bff45181406e422ea988c
[4] https://source.codeaurora.org/external/autobsps32/linux/
[5] https://source.codeaurora.org/external/autobsps32/u-boot/
[6] https://source.codeaurora.org/external/s32ds/compiler/gcc/
[7]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bd3661ea0eb2056852cbc58c5d96bb4df2f164f
[8]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e16feab6cce2b91d2996d4bc4eff01ece577c4a
[9]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9050079719021776e48437827eb9d5986b6e45d4
Eddy Petrișor (1):
dt-bindings: arm: fsl: Add the S32V234-EVB board
Mihaela Martinas (2):
arm64: Introduce config for S32
arm64: defconfig: Enable configs for S32V234
Stefan-Gabriel Mirea (1):
serial: fsl_linflexuart: Be consistent with the name
Stoica Cosmin-Stefan (1):
arm64: dts: fsl: Add device tree for S32V234-EVB
.../admin-guide/kernel-parameters.txt | 2 +-
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/Kconfig.platforms
[PATCH v7 4/5] arm64: dts: fsl: Add device tree for S32V234-EVB
From: Stoica Cosmin-Stefan
Add initial version of device tree for S32V234-EVB, including nodes for the
4 Cortex-A53 cores, AIPS bus with UART modules, ARM architected timer and
Generic Interrupt Controller (GIC).
Keep SoC level separate from board level to let future boards with this SoC
share common properties, while the dts files will keep board-dependent
properties.
Signed-off-by: Stoica Cosmin-Stefan
Signed-off-by: Mihaela Martinas
Signed-off-by: Dan Nica
Signed-off-by: Larisa Grigore
Signed-off-by: Phu Luu An
Signed-off-by: Stefan-Gabriel Mirea
---
arch/arm64/boot/dts/freescale/Makefile| 2 +
arch/arm64/boot/dts/freescale/s32v234-evb.dts | 25
arch/arm64/boot/dts/freescale/s32v234.dtsi| 139 ++
3 files changed, 166 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/s32v234-evb.dts
create mode 100644 arch/arm64/boot/dts/freescale/s32v234.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile
b/arch/arm64/boot/dts/freescale/Makefile
index 93fce8f0c66d..730209adb2bc 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -32,3 +32,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qxp-ai_ml.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb
+
+dtb-$(CONFIG_ARCH_S32) += s32v234-evb.dtb
diff --git a/arch/arm64/boot/dts/freescale/s32v234-evb.dts
b/arch/arm64/boot/dts/freescale/s32v234-evb.dts
new file mode 100644
index ..4b802518cefc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32v234-evb.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2016-2017 NXP
+ */
+
+/dts-v1/;
+#include "s32v234.dtsi"
+
+/ {
+ model = "NXP S32V234-EVB2 Board";
+ compatible = "fsl,s32v234-evb", "fsl,s32v234";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/s32v234.dtsi
b/arch/arm64/boot/dts/freescale/s32v234.dtsi
new file mode 100644
index ..37225191ccbf
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32v234.dtsi
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2016-2018 NXP
+ */
+
+#include
+
+/memreserve/ 0x8000 0x0001;
+
+/ {
+ compatible = "fsl,s32v234";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x0>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8000>;
+ next-level-cache = <&cluster0_l2_cache>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x1>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8000>;
+ next-level-cache = <&cluster0_l2_cache>;
+ };
+
+ cpu2: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x100>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8000>;
+ next-level-cache = <&cluster1_l2_cache>;
+ };
+
+ cpu3: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x101>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8000>;
+ next-level-cache = <&cluster1_l2_cache>;
+ };
+
+ cluster0_l2_cache: l2-cache0 {
+ compatible = "cache";
+ };
+
+ cluster1_l2_cache: l2-cache1 {
+ compatible = "cache";
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ /* clock-frequency might be modified by u-boot, depending on the
+* chip version.
+*/
+ clock-frequency = <1000>;
+ };
+
+ gic: interrupt-controller@7d0010
[PATCH v7 1/5] dt-bindings: arm: fsl: Add the S32V234-EVB board
From: Eddy Petrișor Add entry for the NXP S32V234 Customer Evaluation Board to the board/SoC bindings. Signed-off-by: Eddy Petrișor Signed-off-by: Stefan-Gabriel Mirea Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 1b4b4e6573b5..c211f4f82e25 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -335,4 +335,10 @@ properties: - fsl,ls2088a-rdb - const: fsl,ls2088a + - description: S32V234 based Boards +items: + - enum: + - fsl,s32v234-evb # S32V234-EVB2 Customer Evaluation Board + - const: fsl,s32v234 + ... -- 2.22.0
Re: [PATCH v7 0/5] Add initial support for S32V234-EVB
On Wed, Oct 16, 2019 at 03:48:22PM +0300, Stefan-Gabriel Mirea wrote:
> Hello,
>
> NXP's S32V234[1] ("Treerunner") vision microprocessors are targeted for
> high-performance, computationally intensive vision and sensor fusion
> applications that require automotive safety levels. They include leading
> edge Camera Vision modules like APEX-2, ISP and GPU. The S32V234-EVB and
> S32V234-SBC boards are available for customer evaluation.
>
> The following patch series introduces minimal enablement support for the
> NXP S32V234-EVB2[2] board, which leverages most of the SoC capabilities.
> Up to v2, this series also included the fsl_linflexuart driver, which has
> been included in Linux 5.4-rc1[3].
>
> In the future, we aim to submit multiple drivers upstream, which can be
> found in the kernel of our Auto Linux BSP[4] ("ALB"), starting with basic
> pinmuxing, clock and uSDHC drivers.
>
> For validation, you can use the U-Boot bootloader in the ALB[5], which we
> build and test with our patched version of the Linaro GCC 6.3.1 2017.05
> toolchain for ARM 64-bit, with sources available on [6].
>
> Changes in v7:
> * Rebase the patch 'serial: fsl_linflexuart: Be consistent with the name'
> on the tty-next branch in Greg's tty git tree.
I've taken patch 3 in my tty-next tree. The others should probably go
through an arm-specific tree, right?
thanks,
greg k-h
Re: [PATCH v6 2/2] drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
+TX2_EVENT_ATTR(req_pktsent, CCPI2_EVENT_REQ_PKT_SENT);
+TX2_EVENT_ATTR(snoop_pktsent, CCPI2_EVENT_SNOOP_PKT_SENT);
+TX2_EVENT_ATTR(data_pktsent, CCPI2_EVENT_DATA_PKT_SENT);
+TX2_EVENT_ATTR(gic_pktsent, CCPI2_EVENT_GIC_PKT_SENT);
+
+static struct attribute *ccpi2_pmu_events_attrs[] = {
+ &tx2_pmu_event_attr_req_pktsent.attr.attr,
+ &tx2_pmu_event_attr_snoop_pktsent.attr.attr,
+ &tx2_pmu_event_attr_data_pktsent.attr.attr,
+ &tx2_pmu_event_attr_gic_pktsent.attr.attr,
+ NULL,
+};
Hi Ganapatrao,
Have you considered adding these as uncore pmu-events in the perf tool?
Some advantages I see:
- perf list is not swamped with all these uncore events per PMU
For the Hisi uncore events, we get 100s of events (>600 on the board I
just tested, which is crazy)
- can add more description in the JSON files
- less stuff in the kernel
+
static const struct attribute_group l3c_pmu_events_attr_group = {
.name = "events",
.attrs = l3c_pmu_events_attrs,
@@ -174,6 +240,11 @@ static const struct attribute_group
dmc_pmu_events_attr_group = {
.attrs = dmc_pmu_events_attrs,
};
[...]
tx2_pmu->attr_groups = l3c_pmu_attr_groups;
tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
"uncore_l3c_%d", tx2_pmu->node);
@@ -665,10 +846,13 @@ static struct tx2_uncore_pmu
*tx2_uncore_pmu_init_dev(struct device *dev,
tx2_pmu->stop_event = uncore_stop_event_l3c;
break;
case PMU_TYPE_DMC:
- tx2_pmu->max_counters = TX2_PMU_MAX_COUNTERS;
+ tx2_pmu->max_counters = TX2_PMU_DMC_L3C_MAX_COUNTERS;
+ tx2_pmu->counters_mask = 0x3;
tx2_pmu->prorate_factor = TX2_PMU_DMC_CHANNELS;
tx2_pmu->max_events = DMC_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1f;
tx2_pmu->hrtimer_interval = TX2_PMU_HRTIMER_INTERVAL;
+ tx2_pmu->hrtimer_callback = tx2_hrtimer_callback;
tx2_pmu->attr_groups = dmc_pmu_attr_groups;
tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
"uncore_dmc_%d", tx2_pmu->node);
@@ -676,6 +860,21 @@ static struct tx2_uncore_pmu
*tx2_uncore_pmu_init_dev(struct device *dev,
tx2_pmu->start_event = uncore_start_event_dmc;
tx2_pmu->stop_event = uncore_stop_event_dmc;
break;
+ case PMU_TYPE_CCPI2:
+ /* CCPI2 has 8 counters */
+ tx2_pmu->max_counters = TX2_PMU_CCPI2_MAX_COUNTERS;
+ tx2_pmu->counters_mask = 0x7;
+ tx2_pmu->prorate_factor = 1;
+ tx2_pmu->max_events = CCPI2_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1ff;
+ tx2_pmu->attr_groups = ccpi2_pmu_attr_groups;
+ tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
+ "uncore_ccpi2_%d", tx2_pmu->node);
Do you need to check this for name == NULL?
+ tx2_pmu->init_cntr_base = init_cntr_base_ccpi2;
+ tx2_pmu->start_event = uncore_start_event_ccpi2;
+ tx2_pmu->stop_event = uncore_stop_event_ccpi2;
+ tx2_pmu->hrtimer_callback = NULL;
+ break;
case PMU_TYPE_INVALID:
devm_kfree(dev, tx2_pmu);
return NULL;
@@ -744,7 +943,9 @@ static int tx2_uncore_pmu_offline_cpu(unsigned int cpu,
if (cpu != tx2_pmu->cpu)
return 0;
- hrtimer_cancel(&tx2_pmu->hrtimer);
+ if (tx2_pmu->hrtimer_callback)
+ hrtimer_cancel(&tx2_pmu->hrtimer);
+
cpumask_copy(&cpu_online_mask_temp, cpu_online_mask);
cpumask_clear_cpu(cpu, &cpu_online_mask_temp);
new_cpu = cpumask_any_and(
Thanks,
John
Re: [PATCH v5] printf: add support for printing symbolic error names
On Tue, Oct 15, 2019 at 10:07 PM Rasmus Villemoes
wrote:
> +const char *errname(int err)
> +{
> + const char *name = __errname(err > 0 ? err : -err);
Looks like mine comment left unseen.
What about to simple use abs(err) here?
> + if (!name)
> + return NULL;
> +
> + return err > 0 ? name + 1 : name;
> +}
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
> > diff --git a/Documentation/dev-tools/kcsan.rst > > b/Documentation/dev-tools/kcsan.rst > > new file mode 100644 > > index ..5b46cc5593c3 > > --- /dev/null > > +++ b/Documentation/dev-tools/kcsan.rst > > @@ -0,0 +1,202 @@ > > +The Kernel Concurrency Sanitizer (KCSAN) > > + > > + > > +Overview > > + > > + > > +*Kernel Concurrency Sanitizer (KCSAN)* is a dynamic data-race detector for > > +kernel space. KCSAN is a sampling watchpoint-based data-race detector -- > > this > > +is unlike Kernel Thread Sanitizer (KTSAN), which is a happens-before > > data-race > > +detector. Key priorities in KCSAN's design are lack of false positives, > > +scalability, and simplicity. More details can be found in `Implementation > > +Details`_. > > + > > +KCSAN uses compile-time instrumentation to instrument memory accesses. > > KCSAN is > > +supported in both GCC and Clang. With GCC it requires version 7.3.0 or > > later. > > +With Clang it requires version 7.0.0 or later. > > + > > +Usage > > +- > > + > > +To enable KCSAN configure kernel with:: > > + > > +CONFIG_KCSAN = y > > + > > +KCSAN provides several other configuration options to customize behaviour > > (see > > +their respective help text for more info). > > + > > +debugfs > > +~~~ > > + > > +* The file ``/sys/kernel/debug/kcsan`` can be read to get stats. > > + > > +* KCSAN can be turned on or off by writing ``on`` or ``off`` to > > + ``/sys/kernel/debug/kcsan``. > > + > > +* Writing ``!some_func_name`` to ``/sys/kernel/debug/kcsan`` adds > > + ``some_func_name`` to the report filter list, which (by default) > > blacklists > > + reporting data-races where either one of the top stackframes are a > > function > > + in the list. > > + > > +* Writing either ``blacklist`` or ``whitelist`` to > > ``/sys/kernel/debug/kcsan`` > > + changes the report filtering behaviour. For example, the blacklist > > feature > > + can be used to silence frequently occurring data-races; the whitelist > > feature > > + can help with reproduction and testing of fixes. > > + > > +Error reports > > +~ > > + > > +A typical data-race report looks like this:: > > + > > +== > > +BUG: KCSAN: data-race in generic_permission / kernfs_refresh_inode > > + > > +write to 0x8fee4c40700c of 4 bytes by task 175 on cpu 4: > > + kernfs_refresh_inode+0x70/0x170 > > + kernfs_iop_permission+0x4f/0x90 > > + inode_permission+0x190/0x200 > > + link_path_walk.part.0+0x503/0x8e0 > > + path_lookupat.isra.0+0x69/0x4d0 > > + filename_lookup+0x136/0x280 > > + user_path_at_empty+0x47/0x60 > > + vfs_statx+0x9b/0x130 > > + __do_sys_newlstat+0x50/0xb0 > > + __x64_sys_newlstat+0x37/0x50 > > + do_syscall_64+0x85/0x260 > > + entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > + > > +read to 0x8fee4c40700c of 4 bytes by task 166 on cpu 6: > > + generic_permission+0x5b/0x2a0 > > + kernfs_iop_permission+0x66/0x90 > > + inode_permission+0x190/0x200 > > + link_path_walk.part.0+0x503/0x8e0 > > + path_lookupat.isra.0+0x69/0x4d0 > > + filename_lookup+0x136/0x280 > > + user_path_at_empty+0x47/0x60 > > + do_faccessat+0x11a/0x390 > > + __x64_sys_access+0x3c/0x50 > > + do_syscall_64+0x85/0x260 > > + entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > + > > +Reported by Kernel Concurrency Sanitizer on: > > +CPU: 6 PID: 166 Comm: systemd-journal Not tainted 5.3.0-rc7+ #1 > > +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 > > 04/01/2014 > > +== > > + > > +The header of the report provides a short summary of the functions > > involved in > > +the race. It is followed by the access types and stack traces of the 2 > > threads > > +involved in the data-race. > > + > > +The other less common type of data-race report looks like this:: > > + > > +== > > +BUG: KCSAN: racing read in e1000_clean_rx_irq+0x551/0xb10 > > Do we want to have a different bug title here? Can we also report this > as a data-race to simplify report parsing rules? Changed to just "data-race in" as well. > > + > > +race at unknown origin, with read to 0x933db8a2ae6c of 1 bytes by > > interrupt on cpu 0: > > + e1000_clean_rx_irq+0x551/0xb10 > > + e1000_clean+0x533/0xda0 > > + net_rx_action+0x329/0x900 > > + __do_softirq+0xdb/0x2db > > + irq_exit+0x9b/0xa0 > > + do_IRQ+0x9c/0xf0 > > + ret_from_intr+0x0/0x18 > > + default_idle+0x3f/0x220 > > + arch_cpu_idle+0x21/0x30 > > + do_idle+0x1df/0x230 > > + cpu_startup_entry+0x14/0x20 > > + rest_init+0xc5/0xcb > > + arch_call_rest_init+0x13/0x2b > > + start_kernel+0x6db/0x700 > > + > > +Reported by Kernel Concurrency Sanitizer on: >
Re: [PATCH v5] printf: add support for printing symbolic error names
On Wed 2019-10-16 16:49:41, Andy Shevchenko wrote:
> On Tue, Oct 15, 2019 at 10:07 PM Rasmus Villemoes
> wrote:
>
> > +const char *errname(int err)
> > +{
> > + const char *name = __errname(err > 0 ? err : -err);
>
> Looks like mine comment left unseen.
> What about to simple use abs(err) here?
Andy, would you want to ack the patch with this change?
I could do it when pushing the patch.
Otherwise, it looks ready to go.
Thanks everybody involved for the patience.
Best Regards,
Petr
Re: [PATCH v2] tpm/tpm_ftpm_tee: add shutdown call back
On Mon, Oct 14, 2019 at 04:21:35PM -0400, Pavel Tatashin wrote: > add shutdown call back to close existing session with fTPM TA > to support kexec scenario. Sentences start in English with a capital letter :-) > > Signed-off-by: Thirupathaiah Annapureddy > Signed-off-by: Pavel Tatashin > --- > drivers/char/tpm/tpm_ftpm_tee.c | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c > index 6640a14dbe48..ad16ea555e97 100644 > --- a/drivers/char/tpm/tpm_ftpm_tee.c > +++ b/drivers/char/tpm/tpm_ftpm_tee.c > @@ -328,6 +328,19 @@ static int ftpm_tee_remove(struct platform_device *pdev) > return 0; > } > > +/** > + * ftpm_tee_shutdown - shutdown the TPM device A function name has to have parentheses in kdoc. I know this not consistently done in the subsystem ATM but this is what is documented here: https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt /Jarkko
Re: [PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 2c2e56bd8913..34a1d9310304 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1171,6 +1171,13 @@ struct task_struct {
> #ifdef CONFIG_KASAN
> unsigned intkasan_depth;
> #endif
> +#ifdef CONFIG_KCSAN
> + /* See comments at kernel/kcsan/core.c: struct cpu_state. */
> + int kcsan_disable;
> + int kcsan_atomic_next;
> + int kcsan_atomic_region;
> + boolkcsan_atomic_region_flat;
> +#endif
Should these be unsigned?
> +/*
> + * Per-CPU state that should be used instead of 'current' if we are not in a
> + * task.
> + */
> +struct cpu_state {
> + int disable; /* disable counter */
> + int atomic_next; /* number of following atomic ops */
> +
> + /*
> + * We use separate variables to store if we are in a nestable or flat
> + * atomic region. This helps make sure that an atomic region with
> + * nesting support is not suddenly aborted when a flat region is
> + * contained within. Effectively this allows supporting nesting flat
> + * atomic regions within an outer nestable atomic region. Support for
> + * this is required as there are cases where a seqlock reader critical
> + * section (flat atomic region) is contained within a seqlock writer
> + * critical section (nestable atomic region), and the "mismatching
> + * kcsan_end_atomic()" warning would trigger otherwise.
> + */
> + int atomic_region;
> + bool atomic_region_flat;
> +};
> +static DEFINE_PER_CPU(struct cpu_state, this_state) = {
> + .disable = 0,
> + .atomic_next = 0,
> + .atomic_region = 0,
> + .atomic_region_flat = 0,
> +};
These are the same as in task_struct, so I think it probably makes sense
to have a common structure for these, e.g.
| struct kcsan_ctx {
| int disable;
| int atomic_next;
| int atomic_region;
| boolatomic_region_flat;
| };
... which you then place within task_struct, e.g.
| #ifdef CONFIG_KCSAN
| struct kcsan_ctxkcsan_ctx;
| #endif
... and here, e.g.
| static DEFINE_PER_CPU(struct kcsan_ctx, kcsan_cpu_ctx);
That would simplify a number of cases below where you have to choose one
or the other, as you can choose the pointer, then handle the rest in a
common way.
e.g. for:
> +static inline bool is_atomic(const volatile void *ptr)
> +{
> + if (in_task()) {
> + if (unlikely(current->kcsan_atomic_next > 0)) {
> + --current->kcsan_atomic_next;
> + return true;
> + }
> + if (unlikely(current->kcsan_atomic_region > 0 ||
> + current->kcsan_atomic_region_flat))
> + return true;
> + } else { /* interrupt */
> + if (unlikely(this_cpu_read(this_state.atomic_next) > 0)) {
> + this_cpu_dec(this_state.atomic_next);
> + return true;
> + }
> + if (unlikely(this_cpu_read(this_state.atomic_region) > 0 ||
> + this_cpu_read(this_state.atomic_region_flat)))
> + return true;
> + }
> +
> + return kcsan_is_atomic(ptr);
> +}
... you could have something like:
| struct kcsan_ctx *kcsan_get_ctx(void)
| {
| return in_task() ? ¤t->kcsan_ctx : this_cpu_ptr(kcsan_cpu_ctx);
| }
|
| static inline bool is_atomic(const volatile void *ptr)
| {
| struct kcsan_ctx *ctx = kcsan_get_ctx();
| if (unlikely(ctx->atomic_next > 0) {
| --ctx->atomic_next;
| return true;
| }
| if (unlikely(ctx->atomic_region > 0 || ctx->atomic_region_flat))
| return true;
|
| return kcsan_is_atomic(ptr);
| }
... avoiding duplicating the checks for task/irq contexts.
It's not clear to me how either that or the original code works if a
softirq is interrupted by a hardirq. IIUC most of the fields should
remain stable over that window, since the hardirq should balance most
changes it makes before returning, but I don't think that's true for
atomic_next. Can't that be corrupted from the PoV of the softirq
handler?
[...]
> +void kcsan_begin_atomic(bool nest)
> +{
> + if (nest) {
> + if (in_task())
> + ++current->kcsan_atomic_region;
> + else
> + this_cpu_inc(this_state.atomic_region);
> + } else {
> + if (in_task())
> + current->kcsan_atomic_region_flat = true;
> + else
> + this_cpu_write(this_state.atomic_region_flat, true);
> + }
> +}
Assuming my suggestion above wasn't bogus, this can be:
| void kcsan_begin_atomic(boot nest)
| {
| struct kcsan_ctx *ctx = kcsan_get_ctx()
Re: [PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
On Wed, 16 Oct 2019 at 17:16, Mark Rutland wrote:
>
> On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 2c2e56bd8913..34a1d9310304 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -1171,6 +1171,13 @@ struct task_struct {
> > #ifdef CONFIG_KASAN
> > unsigned intkasan_depth;
> > #endif
> > +#ifdef CONFIG_KCSAN
> > + /* See comments at kernel/kcsan/core.c: struct cpu_state. */
> > + int kcsan_disable;
> > + int kcsan_atomic_next;
> > + int kcsan_atomic_region;
> > + boolkcsan_atomic_region_flat;
> > +#endif
>
> Should these be unsigned?
I prefer to keep them int, as they can become negative (rather than
underflow with unsigned), if we e.g. have unbalanced
kcsan_enable_current etc. Since we do not need the full unsigned range
(these values should stay relatively small), int is more than enough.
> > +/*
> > + * Per-CPU state that should be used instead of 'current' if we are not in
> > a
> > + * task.
> > + */
> > +struct cpu_state {
> > + int disable; /* disable counter */
> > + int atomic_next; /* number of following atomic ops */
> > +
> > + /*
> > + * We use separate variables to store if we are in a nestable or flat
> > + * atomic region. This helps make sure that an atomic region with
> > + * nesting support is not suddenly aborted when a flat region is
> > + * contained within. Effectively this allows supporting nesting flat
> > + * atomic regions within an outer nestable atomic region. Support for
> > + * this is required as there are cases where a seqlock reader critical
> > + * section (flat atomic region) is contained within a seqlock writer
> > + * critical section (nestable atomic region), and the "mismatching
> > + * kcsan_end_atomic()" warning would trigger otherwise.
> > + */
> > + int atomic_region;
> > + bool atomic_region_flat;
> > +};
> > +static DEFINE_PER_CPU(struct cpu_state, this_state) = {
> > + .disable = 0,
> > + .atomic_next = 0,
> > + .atomic_region = 0,
> > + .atomic_region_flat = 0,
> > +};
>
> These are the same as in task_struct, so I think it probably makes sense
> to have a common structure for these, e.g.
>
> | struct kcsan_ctx {
> | int disable;
> | int atomic_next;
> | int atomic_region;
> | boolatomic_region_flat;
> | };
>
> ... which you then place within task_struct, e.g.
>
> | #ifdef CONFIG_KCSAN
> | struct kcsan_ctxkcsan_ctx;
> | #endif
>
> ... and here, e.g.
>
> | static DEFINE_PER_CPU(struct kcsan_ctx, kcsan_cpu_ctx);
>
> That would simplify a number of cases below where you have to choose one
> or the other, as you can choose the pointer, then handle the rest in a
> common way.
>
> e.g. for:
>
> > +static inline bool is_atomic(const volatile void *ptr)
> > +{
> > + if (in_task()) {
> > + if (unlikely(current->kcsan_atomic_next > 0)) {
> > + --current->kcsan_atomic_next;
> > + return true;
> > + }
> > + if (unlikely(current->kcsan_atomic_region > 0 ||
> > + current->kcsan_atomic_region_flat))
> > + return true;
> > + } else { /* interrupt */
> > + if (unlikely(this_cpu_read(this_state.atomic_next) > 0)) {
> > + this_cpu_dec(this_state.atomic_next);
> > + return true;
> > + }
> > + if (unlikely(this_cpu_read(this_state.atomic_region) > 0 ||
> > + this_cpu_read(this_state.atomic_region_flat)))
> > + return true;
> > + }
> > +
> > + return kcsan_is_atomic(ptr);
> > +}
>
> ... you could have something like:
>
> | struct kcsan_ctx *kcsan_get_ctx(void)
> | {
> | return in_task() ? ¤t->kcsan_ctx : this_cpu_ptr(kcsan_cpu_ctx);
> | }
> |
> | static inline bool is_atomic(const volatile void *ptr)
> | {
> | struct kcsan_ctx *ctx = kcsan_get_ctx();
> | if (unlikely(ctx->atomic_next > 0) {
> | --ctx->atomic_next;
> | return true;
> | }
> | if (unlikely(ctx->atomic_region > 0 || ctx->atomic_region_flat))
> | return true;
> |
> | return kcsan_is_atomic(ptr);
> | }
>
> ... avoiding duplicating the checks for task/irq contexts.
>
> It's not clear to me how either that or the original code works if a
> softirq is interrupted by a hardirq. IIUC most of the fields should
> remain stable over that window, since the hardirq should balance most
> changes it makes before returning, but I don't think that's true for
> atomic_next. Can't that be corrupted from the PoV of the softirq
> handler?
As you say, these fields should balance. So far I have not o
Re: [PATCH 8/8] x86, kcsan: Enable KCSAN for x86
On 10/16/19 1:39 AM, Marco Elver wrote: > This patch enables KCSAN for x86, with updates to build rules to not use > KCSAN for several incompatible compilation units. First of all KCSAN looks really interesting! For the x86 code, though, I'd really appreciate some specific notes on why individual compilation units are incompatible. There might be some that were missed, and we have to figure out what we do for any future work. Knowing the logic used on these would be really helpful in the future.
[PATCH v3] tpm/tpm_ftpm_tee: add shutdown call back
Add shutdown call back to close existing session with fTPM TA
to support kexec scenario.
Add parentheses to function names in comments as specified in kdoc.
Signed-off-by: Thirupathaiah Annapureddy
Signed-off-by: Pavel Tatashin
---
drivers/char/tpm/tpm_ftpm_tee.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
index 6640a14dbe48..22bf553ccf9d 100644
--- a/drivers/char/tpm/tpm_ftpm_tee.c
+++ b/drivers/char/tpm/tpm_ftpm_tee.c
@@ -32,7 +32,7 @@ static const uuid_t ftpm_ta_uuid =
0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x96);
/**
- * ftpm_tee_tpm_op_recv - retrieve fTPM response.
+ * ftpm_tee_tpm_op_recv() - retrieve fTPM response.
* @chip: the tpm_chip description as specified in driver/char/tpm/tpm.h.
* @buf: the buffer to store data.
* @count: the number of bytes to read.
@@ -61,7 +61,7 @@ static int ftpm_tee_tpm_op_recv(struct tpm_chip *chip, u8
*buf, size_t count)
}
/**
- * ftpm_tee_tpm_op_send - send TPM commands through the TEE shared memory.
+ * ftpm_tee_tpm_op_send() - send TPM commands through the TEE shared memory.
* @chip: the tpm_chip description as specified in driver/char/tpm/tpm.h
* @buf: the buffer to send.
* @len: the number of bytes to send.
@@ -208,7 +208,7 @@ static int ftpm_tee_match(struct tee_ioctl_version_data
*ver, const void *data)
}
/**
- * ftpm_tee_probe - initialize the fTPM
+ * ftpm_tee_probe() - initialize the fTPM
* @pdev: the platform_device description.
*
* Return:
@@ -298,7 +298,7 @@ static int ftpm_tee_probe(struct platform_device *pdev)
}
/**
- * ftpm_tee_remove - remove the TPM device
+ * ftpm_tee_remove() - remove the TPM device
* @pdev: the platform_device description.
*
* Return:
@@ -328,6 +328,19 @@ static int ftpm_tee_remove(struct platform_device *pdev)
return 0;
}
+/**
+ * ftpm_tee_shutdown() - shutdown the TPM device
+ * @pdev: the platform_device description.
+ */
+static void ftpm_tee_shutdown(struct platform_device *pdev)
+{
+ struct ftpm_tee_private *pvt_data = dev_get_drvdata(&pdev->dev);
+
+ tee_shm_free(pvt_data->shm);
+ tee_client_close_session(pvt_data->ctx, pvt_data->session);
+ tee_client_close_context(pvt_data->ctx);
+}
+
static const struct of_device_id of_ftpm_tee_ids[] = {
{ .compatible = "microsoft,ftpm" },
{ }
@@ -341,6 +354,7 @@ static struct platform_driver ftpm_tee_driver = {
},
.probe = ftpm_tee_probe,
.remove = ftpm_tee_remove,
+ .shutdown = ftpm_tee_shutdown,
};
module_platform_driver(ftpm_tee_driver);
--
2.23.0
Re: [PATCH v5] printf: add support for printing symbolic error names
On Wed, Oct 16, 2019 at 5:52 PM Petr Mladek wrote:
>
> On Wed 2019-10-16 16:49:41, Andy Shevchenko wrote:
> > On Tue, Oct 15, 2019 at 10:07 PM Rasmus Villemoes
> > wrote:
> >
> > > +const char *errname(int err)
> > > +{
> > > + const char *name = __errname(err > 0 ? err : -err);
> >
> > Looks like mine comment left unseen.
> > What about to simple use abs(err) here?
>
> Andy, would you want to ack the patch with this change?
> I could do it when pushing the patch.
Looks good to me.
Acked-by: Andy Shevchenko
>
> Otherwise, it looks ready to go.
>
> Thanks everybody involved for the patience.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2] tpm/tpm_ftpm_tee: add shutdown call back
On Wed, Oct 16, 2019 at 11:12 AM Jarkko Sakkinen wrote: > > On Mon, Oct 14, 2019 at 04:21:35PM -0400, Pavel Tatashin wrote: > > add shutdown call back to close existing session with fTPM TA > > to support kexec scenario. > > Sentences start in English with a capital letter :-) > OK * > > + * ftpm_tee_shutdown - shutdown the TPM device > > A function name has to have parentheses in kdoc. I know this not > consistently done in the subsystem ATM but this is what is documented > here: > > https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt > OK. A new version is sent out. Pasha
[PATCH] thermal: update header and documentation
The commit commit f991de53a8ab ("thermal: make device_register's type
argument const") changed APIs, but only when CONFIG_THERMAL enabled case.
This patch is partial from https://lkml.org/lkml/2019/5/14/631 which
tries to address the same concern,
Signed-off-by: Wei Wang
---
Documentation/driver-api/thermal/sysfs-api.rst | 4 ++--
include/linux/thermal.h| 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/driver-api/thermal/sysfs-api.rst
b/Documentation/driver-api/thermal/sysfs-api.rst
index fab2c9b36d08..0ef337417922 100644
--- a/Documentation/driver-api/thermal/sysfs-api.rst
+++ b/Documentation/driver-api/thermal/sysfs-api.rst
@@ -39,7 +39,7 @@ temperature) and throttle appropriate devices.
::
struct thermal_zone_device
- *thermal_zone_device_register(char *type,
+ *thermal_zone_device_register(const char *type,
int trips, int mask, void *devdata,
struct thermal_zone_device_ops *ops,
const struct thermal_zone_params *tzp,
@@ -221,7 +221,7 @@ temperature) and throttle appropriate devices.
::
struct thermal_cooling_device
- *thermal_cooling_device_register(char *name,
+ *thermal_cooling_device_register(const char *name,
void *devdata, struct thermal_cooling_device_ops *)
This interface function adds a new thermal cooling device
(fan/processor/...)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index e45659c75920..ee235a29294e 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -501,12 +501,12 @@ static inline void thermal_zone_device_update(struct
thermal_zone_device *tz,
static inline void thermal_zone_set_trips(struct thermal_zone_device *tz)
{ }
static inline struct thermal_cooling_device *
-thermal_cooling_device_register(char *type, void *devdata,
+thermal_cooling_device_register(const char *type, void *devdata,
const struct thermal_cooling_device_ops *ops)
{ return ERR_PTR(-ENODEV); }
static inline struct thermal_cooling_device *
-thermal_of_cooling_device_register(struct device_node *np,
- char *type, void *devdata, const struct thermal_cooling_device_ops *ops)
+thermal_of_cooling_device_register(struct device_node *np, const char *type,
+ void *devdata, const struct thermal_cooling_device_ops *ops)
{ return ERR_PTR(-ENODEV); }
static inline struct thermal_cooling_device *
devm_thermal_of_cooling_device_register(struct device *dev,
--
2.23.0.700.g56cf767bdb-goog
Re: [PATCH v7 0/5] Add initial support for S32V234-EVB
On 10/16/2019 4:17 PM, Greg KH wrote: > > I've taken patch 3 in my tty-next tree. The others should probably go > through an arm-specific tree, right? Thank you very much, Greg! That was all for the tty tree. I think that the other patches should go to the following trees: * git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git: patches #1 and possibly #4 (as it covers arch/*/boot/dts/); * git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git: patches #2, #5 and possibly #4 (as it covers arch/arm64/boot/dts/) * git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git possibly patch #4 (as it covers arch/arm64/boot/dts/freescale/fsl-*) As a general question, would it be any chance to have the device tree included in v5.4 (along with its compatible documentation and config definition, without enablement)? That is, only the patches #1, #2 and #4, because #3 is a cosmetic change and #5 enables the new configs by default. That would complete a minimal support for S32V234-EVB, together with the LINFlexD UART driver which was accepted. >From the development process documentation[1]: "An occasional exception is made for drivers for previously-unsupported hardware; if they touch no in-tree code, they cannot cause regressions and should be safe to add at any time". I know that it mentions only drivers and not device trees, but from the history is seems that there have also been dts/dtsi files added outside of merge windows, such as: * arch/riscv/boot/dts/sifive/fu540-c000.dtsi; * arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts; * arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts; * arch/xtensa/boot/dts/lx200mx.dts; * arch/xtensa/boot/dts/kc705.dts; * arch/xtensa/boot/dts/xtfpga-flash-128m.dtsi; * arch/arm/boot/dts/omap3-beagle-xm-ab.dts; * arch/arm/boot/dts/at91-sama5d3_xplained.dts; * arch/arm/boot/dts/am335x-boneblack.dts; * arch/powerpc/boot/dts/charon.dts. I am sorry if my question is inopportune, I am definitely not trying to rush anyone. I just ask because this has been under review for some time and all the feedback has been addressed. We would really appreciate to have this SoC and board supported in the following LTS release if there are no other issues. Regards, Stefan [1] https://www.kernel.org/doc/html/v5.3/process/2.Process.html
Re: [PATCH 8/8] x86, kcsan: Enable KCSAN for x86
On Wed, 16 Oct 2019 at 18:14, Dave Hansen wrote: > > On 10/16/19 1:39 AM, Marco Elver wrote: > > This patch enables KCSAN for x86, with updates to build rules to not use > > KCSAN for several incompatible compilation units. > > First of all KCSAN looks really interesting! > > For the x86 code, though, I'd really appreciate some specific notes on > why individual compilation units are incompatible. There might be some > that were missed, and we have to figure out what we do for any future > work. Knowing the logic used on these would be really helpful in the > future. Thanks! I will add comments where I can for v2. For most of them, I followed the examples of KASAN and co, and will try to reevaluate each one. -- Marco
Re: [PATCH v10 4/6] mfd: ioc3: Add driver for SGI IOC3 chip
On Wed, 16 Oct 2019 19:23:21 +0200, Thomas Bogendoerfer wrote: > On Tue, 15 Oct 2019 12:23:49 -0700 > Jakub Kicinski wrote: > > > On Tue, 15 Oct 2019 14:09:49 +0200, Thomas Bogendoerfer wrote: > > > SGI IOC3 chip has integrated ethernet, keyboard and mouse interface. > > > It also supports connecting a SuperIO chip for serial and parallel > > > interfaces. IOC3 is used inside various SGI systemboards and add-on > > > cards with different equipped external interfaces. > > > > > > Support for ethernet and serial interfaces were implemented inside > > > the network driver. This patchset moves out the not network related > > > parts to a new MFD driver, which takes care of card detection, > > > setup of platform devices and interrupt distribution for the subdevices. > > > > > > Serial portion: Acked-by: Greg Kroah-Hartman > > > Acked-for-MFD-by: Lee Jones > > > > > > Signed-off-by: Thomas Bogendoerfer > > > > Looks good, I think. > > thank you. > > Now how do I get an Acked-by for the network part to merge it via > the MIPS tree ? Oh, via the MIPS tree? It was quite unclear which these would land it, at least to an untrained mind like mine :) It could be useful to provide some info on how you want this merged and what you expect from whom in the cover letter in the future. Hopefully Dave will be able to give you an official ack.
Re: [PATCH v10 4/6] mfd: ioc3: Add driver for SGI IOC3 chip
On Tue, 15 Oct 2019 12:23:49 -0700 Jakub Kicinski wrote: > On Tue, 15 Oct 2019 14:09:49 +0200, Thomas Bogendoerfer wrote: > > SGI IOC3 chip has integrated ethernet, keyboard and mouse interface. > > It also supports connecting a SuperIO chip for serial and parallel > > interfaces. IOC3 is used inside various SGI systemboards and add-on > > cards with different equipped external interfaces. > > > > Support for ethernet and serial interfaces were implemented inside > > the network driver. This patchset moves out the not network related > > parts to a new MFD driver, which takes care of card detection, > > setup of platform devices and interrupt distribution for the subdevices. > > > > Serial portion: Acked-by: Greg Kroah-Hartman > > Acked-for-MFD-by: Lee Jones > > > > Signed-off-by: Thomas Bogendoerfer > > Looks good, I think. thank you. Now how do I get an Acked-by for the network part to merge it via the MIPS tree ? Thomas. -- SUSE Software Solutions Germany GmbH HRB 36809 (AG Nürnberg) Geschäftsführer: Felix Imendörffer
Re: [PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
> +bool __kcsan_check_watchpoint(const volatile void *ptr, size_t size,
> + bool is_write)
> +{
> + atomic_long_t *watchpoint;
> + long encoded_watchpoint;
> + unsigned long flags;
> + enum kcsan_report_type report_type;
> +
> + if (unlikely(!is_enabled()))
> + return false;
> +
> + watchpoint = find_watchpoint((unsigned long)ptr, size, !is_write,
> + &encoded_watchpoint);
> + if (watchpoint == NULL)
> + return true;
> +
> + flags = user_access_save();
Could use a comment on why find_watchpoint() is save to call without
user_access_save() on.
> + if (!try_consume_watchpoint(watchpoint, encoded_watchpoint)) {
> + /*
> + * The other thread may not print any diagnostics, as it has
> + * already removed the watchpoint, or another thread consumed
> + * the watchpoint before this thread.
> + */
> + kcsan_counter_inc(kcsan_counter_report_races);
> + report_type = kcsan_report_race_check_race;
> + } else {
> + report_type = kcsan_report_race_check;
> + }
> +
> + /* Encountered a data-race. */
> + kcsan_counter_inc(kcsan_counter_data_races);
> + kcsan_report(ptr, size, is_write, raw_smp_processor_id(), report_type);
> +
> + user_access_restore(flags);
> + return false;
> +}
> +EXPORT_SYMBOL(__kcsan_check_watchpoint);
> +
> +void __kcsan_setup_watchpoint(const volatile void *ptr, size_t size,
> + bool is_write)
> +{
> + atomic_long_t *watchpoint;
> + union {
> + u8 _1;
> + u16 _2;
> + u32 _4;
> + u64 _8;
> + } expect_value;
> + bool is_expected = true;
> + unsigned long ua_flags = user_access_save();
> + unsigned long irq_flags;
> +
> + if (!should_watch(ptr))
> + goto out;
> +
> + if (!check_encodable((unsigned long)ptr, size)) {
> + kcsan_counter_inc(kcsan_counter_unencodable_accesses);
> + goto out;
> + }
> +
> + /*
> + * Disable interrupts & preemptions, to ignore races due to accesses in
> + * threads running on the same CPU.
> + */
> + local_irq_save(irq_flags);
> + preempt_disable();
Is there a point to that preempt_disable() here?
Re: [PATCH v3 2/3] kernel/ucounts: expose count of inotify watches in use
On Sat, Jun 1, 2019 at 8:20 PM Albert Vaca Cintora
wrote:
>
> On Sat, Jun 1, 2019 at 2:00 AM Andrew Morton
> wrote:
> >
> > On Fri, 31 May 2019 21:50:15 +0200 Albert Vaca Cintora
> > wrote:
> >
> > > Adds a readonly 'current_inotify_watches' entry to the user sysctl table.
> > > The handler for this entry is a custom function that ends up calling
> > > proc_dointvec. Said sysctl table already contains 'max_inotify_watches'
> > > and it gets mounted under /proc/sys/user/.
> > >
> > > Inotify watches are a finite resource, in a similar way to available file
> > > descriptors. The motivation for this patch is to be able to set up
> > > monitoring and alerting before an application starts failing because
> > > it runs out of inotify watches.
> > >
> > > ...
> > >
> > > --- a/kernel/ucount.c
> > > +++ b/kernel/ucount.c
> > > @@ -118,6 +118,26 @@ static void put_ucounts(struct ucounts *ucounts)
> > > kfree(ucounts);
> > > }
> > >
> > > +#ifdef CONFIG_INOTIFY_USER
> > > +int proc_read_inotify_watches(struct ctl_table *table, int write,
> > > + void __user *buffer, size_t *lenp, loff_t *ppos)
> > > +{
> > > + struct ucounts *ucounts;
> > > + struct ctl_table fake_table;
> >
> > hmm.
> >
> > > + int count = -1;
> > > +
> > > + ucounts = get_ucounts(current_user_ns(), current_euid());
> > > + if (ucounts != NULL) {
> > > + count =
> > > atomic_read(&ucounts->ucount[UCOUNT_INOTIFY_WATCHES]);
> > > + put_ucounts(ucounts);
> > > + }
> > > +
> > > + fake_table.data = &count;
> > > + fake_table.maxlen = sizeof(count);
> > > + return proc_dointvec(&fake_table, write, buffer, lenp, ppos);
> >
> > proc_dointvec
> > ->do_proc_dointvec
> > ->__do_proc_dointvec
> > ->proc_first_pos_non_zero_ignore
> > ->warn_sysctl_write
> > ->pr_warn_once(..., table->procname)
> >
> > and I think ->procname is uninitialized.
> >
> > That's from a cursory check. Perhaps other uninitialized members of
> > fake_table are accessed, dunno.
> >
> > we could do
> >
> > {
> > struct ctl_table fake_table = {
> > .data = &count,
> > .maxlen = sizeof(count),
> > };
> >
> > return proc_dointvec(&fake_table, write, buffer, lenp,
> > ppos);
> > }
> >
> > or whatever. That will cause the pr_warn_once to print "(null)" but
> > that's OK I guess.
> >
> > Are there other places in the kernel which do this temp ctl_table
> > trick? If so, what do they do? If not, what is special about this
> > code?
> >
> >
>
> I copied this 'fake_table' trick from proc_do_entropy in
> drivers/char/random.c exactly as it is. It is also used in other
> places with slight variations.
>
> Note that, since we are creating a read-only proc file,
> proc_first_pos_non_zero_ignore is not called from __do_proc_dointvec,
> so the uninitialized ->procname is not accessed.
>
Friendly ping. I think the code is correct as it is for the reasons
explained above.
Best regards,
Albert
Re: [PATCH v3 1/3] kasan: Archs don't check memmove if not support it.
On Mon, 07 Oct 2019 23:11:51 PDT (-0700), nic...@andestech.com wrote:
Skip the memmove checking for those archs who don't support it.
Signed-off-by: Nick Hu
---
mm/kasan/common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 6814d6d6a023..897f9520bab3 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -107,6 +107,7 @@ void *memset(void *addr, int c, size_t len)
return __memset(addr, c, len);
}
+#ifdef __HAVE_ARCH_MEMMOVE
#undef memmove
void *memmove(void *dest, const void *src, size_t len)
{
@@ -115,6 +116,7 @@ void *memmove(void *dest, const void *src, size_t len)
return __memmove(dest, src, len);
}
+#endif
#undef memcpy
void *memcpy(void *dest, const void *src, size_t len)
I think this is backwards: we shouldn't be defining an arch-specific memmove
symbol when KASAN is enabled. If we do it this way then we're defeating the
memmove checks, which doesn't seem like the right way to go.
Re: [PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
On Wed, 16 Oct 2019 at 20:44, Peter Zijlstra wrote:
>
> On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
>
> > +bool __kcsan_check_watchpoint(const volatile void *ptr, size_t size,
> > + bool is_write)
> > +{
> > + atomic_long_t *watchpoint;
> > + long encoded_watchpoint;
> > + unsigned long flags;
> > + enum kcsan_report_type report_type;
> > +
> > + if (unlikely(!is_enabled()))
> > + return false;
> > +
> > + watchpoint = find_watchpoint((unsigned long)ptr, size, !is_write,
> > + &encoded_watchpoint);
> > + if (watchpoint == NULL)
> > + return true;
> > +
> > + flags = user_access_save();
>
> Could use a comment on why find_watchpoint() is save to call without
> user_access_save() on.
Thanks, will add a comment for v2.
> > + if (!try_consume_watchpoint(watchpoint, encoded_watchpoint)) {
> > + /*
> > + * The other thread may not print any diagnostics, as it has
> > + * already removed the watchpoint, or another thread consumed
> > + * the watchpoint before this thread.
> > + */
> > + kcsan_counter_inc(kcsan_counter_report_races);
> > + report_type = kcsan_report_race_check_race;
> > + } else {
> > + report_type = kcsan_report_race_check;
> > + }
> > +
> > + /* Encountered a data-race. */
> > + kcsan_counter_inc(kcsan_counter_data_races);
> > + kcsan_report(ptr, size, is_write, raw_smp_processor_id(),
> > report_type);
> > +
> > + user_access_restore(flags);
> > + return false;
> > +}
> > +EXPORT_SYMBOL(__kcsan_check_watchpoint);
> > +
> > +void __kcsan_setup_watchpoint(const volatile void *ptr, size_t size,
> > + bool is_write)
> > +{
> > + atomic_long_t *watchpoint;
> > + union {
> > + u8 _1;
> > + u16 _2;
> > + u32 _4;
> > + u64 _8;
> > + } expect_value;
> > + bool is_expected = true;
> > + unsigned long ua_flags = user_access_save();
> > + unsigned long irq_flags;
> > +
> > + if (!should_watch(ptr))
> > + goto out;
> > +
> > + if (!check_encodable((unsigned long)ptr, size)) {
> > + kcsan_counter_inc(kcsan_counter_unencodable_accesses);
> > + goto out;
> > + }
> > +
> > + /*
> > + * Disable interrupts & preemptions, to ignore races due to accesses
> > in
> > + * threads running on the same CPU.
> > + */
> > + local_irq_save(irq_flags);
> > + preempt_disable();
>
> Is there a point to that preempt_disable() here?
We want to avoid being preempted while the watchpoint is set up;
otherwise, we would report data-races for CPU-local data, which is
incorrect. An alternative would be adding the source CPU to the
watchpoint, and checking that the CPU != this_cpu. There are several
problems with that alternative:
1. We do not want to steal more bits from the watchpoint encoding for
things other than read/write, size, and address, as not only does it
affect accuracy, it would also increase performance overhead in the
fast-path.
2. As a consequence, if we get a preemption and run a task on the same
CPU, and there *is* a genuine data-race, we would *not* report it; and
since this is the common case (and not accesses to CPU-local data), it
makes more sense (from a data-race detection PoV) to simply disable
preemptions and ensure that all tasks are run on other CPUs as well as
avoid the problem of point (1).
I can add a comment to that effect here for v2.
Thanks,
-- Marco
[PATCH] Updated iostats docs
Previous docs mentioned 11 unsigned long fields, when the reality is that we have 15 fields with a mix of unsigned long and unsigned int. Signed-off-by: Albert Vaca Cintora --- Documentation/admin-guide/iostats.rst | 47 ++- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/Documentation/admin-guide/iostats.rst b/Documentation/admin-guide/iostats.rst index 5d63b18bd6d1..321aae8d7e10 100644 --- a/Documentation/admin-guide/iostats.rst +++ b/Documentation/admin-guide/iostats.rst @@ -46,78 +46,79 @@ each snapshot of your disk statistics. In 2.4, the statistics fields are those after the device name. In the above example, the first field of statistics would be 446216. By contrast, in 2.6+ if you look at ``/sys/block/hda/stat``, you'll -find just the eleven fields, beginning with 446216. If you look at -``/proc/diskstats``, the eleven fields will be preceded by the major and +find just the 15 fields, beginning with 446216. If you look at +``/proc/diskstats``, the 15 fields will be preceded by the major and minor device numbers, and device name. Each of these formats provides -eleven fields of statistics, each meaning exactly the same things. +15 fields of statistics, each meaning exactly the same things. All fields except field 9 are cumulative since boot. Field 9 should go to zero as I/Os complete; all others only increase (unless they -overflow and wrap). Yes, these are (32-bit or 64-bit) unsigned long -(native word size) numbers, and on a very busy or long-lived system they -may wrap. Applications should be prepared to deal with that; unless -your observations are measured in large numbers of minutes or hours, -they should not wrap twice before you notice them. +overflow and wrap). Wrapping might eventually occur on a very busy +or long-lived system; so applications should be prepared to deal with +it. Regarding wrapping, the types of the fields are either unsigned +int (32 bit) or unsigned long (32-bit or 64-bit, depending on your +machine) as noted per-field below. Unless your observations are very +spread in time, these fields should not wrap twice before you notice it. Each set of stats only applies to the indicated device; if you want system-wide stats you'll have to find all the devices and sum them all up. -Field 1 -- # of reads completed +Field 1 -- # of reads completed (unsigned long) This is the total number of reads completed successfully. -Field 2 -- # of reads merged, field 6 -- # of writes merged +Field 2 -- # of reads merged, field 6 -- # of writes merged (unsigned long) Reads and writes which are adjacent to each other may be merged for efficiency. Thus two 4K reads may become one 8K read before it is ultimately handed to the disk, and so it will be counted (and queued) as only one I/O. This field lets you know how often this was done. -Field 3 -- # of sectors read +Field 3 -- # of sectors read (unsigned long) This is the total number of sectors read successfully. -Field 4 -- # of milliseconds spent reading +Field 4 -- # of milliseconds spent reading (unsigned int) This is the total number of milliseconds spent by all reads (as measured from __make_request() to end_that_request_last()). -Field 5 -- # of writes completed +Field 5 -- # of writes completed (unsigned long) This is the total number of writes completed successfully. -Field 6 -- # of writes merged +Field 6 -- # of writes merged (unsigned long) See the description of field 2. -Field 7 -- # of sectors written +Field 7 -- # of sectors written (unsigned long) This is the total number of sectors written successfully. -Field 8 -- # of milliseconds spent writing +Field 8 -- # of milliseconds spent writing (unsigned int) This is the total number of milliseconds spent by all writes (as measured from __make_request() to end_that_request_last()). -Field 9 -- # of I/Os currently in progress +Field 9 -- # of I/Os currently in progress (unsigned int) The only field that should go to zero. Incremented as requests are given to appropriate struct request_queue and decremented as they finish. -Field 10 -- # of milliseconds spent doing I/Os +Field 10 -- # of milliseconds spent doing I/Os (unsigned int) This field increases so long as field 9 is nonzero. Since 5.0 this field counts jiffies when at least one request was started or completed. If request runs more than 2 jiffies then some I/O time will not be accounted unless there are other requests. -Field 11 -- weighted # of milliseconds spent doing I/Os +Field 11 -- weighted # of milliseconds spent doing I/Os (unsigned int) This field is incremented at each I/O start, I/O completion, I/O merge, or read of these stats by the number of I/Os in progress (field 9) times the number of milliseconds spent doing I/O since the last update of this field. This can provide an easy measure of both
Re: [PATCH v11 3/6] of: property: Add functional dependency link from DT bindings
Quoting Saravana Kannan (2019-10-08 11:57:49) > On Tue, Oct 8, 2019 at 7:53 AM Stephen Boyd wrote: > > > > Quoting Greg Kroah-Hartman (2019-10-04 08:37:50) > > > On Wed, Sep 11, 2019 at 03:29:25AM -0700, Stephen Boyd wrote: > > > > Quoting Saravana Kannan (2019-09-04 14:11:22) > > > > > + int ret = 0; > > > > > + struct device_node *tmp_np = sup_np; > > > > > + > > > > > + of_node_get(sup_np); > > > > > + /* > > > > > +* Find the device node that contains the supplier phandle. > > > > > It may be > > > > > +* @sup_np or it may be an ancestor of @sup_np. > > > > > +*/ > > > > > + while (sup_np && !of_find_property(sup_np, "compatible", > > > > > NULL)) > > > > > + sup_np = of_get_next_parent(sup_np); > > > > > > > > I don't get this. This is assuming that drivers are only probed for > > > > device nodes that have a compatible string? What about drivers that make > > > > sub-devices for clk support that have drivers in drivers/clk/ that then > > > > attach at runtime later? This happens sometimes for MFDs that want to > > > > split the functionality across the driver tree to the respective > > > > subsystems. > > > > > > For that, the link would not be there, correct? > > > > The parent device (MFD) would have the links because that is the device > > node with the provider property like '#clock-cells'. The child clk > > device that's populated by the MFD would be the one actually providing > > the clk via a driver that may probe any time later, or never, depending > > on if the clk driver is configured as a module or not. I fail to see how > > this will work for these cases. > > > > Is this logic there to find the parent of a regulator phandle and match > > that to some driver? It looks like it. > > In the case of an MFD creating "fake" children devices, the parent MFD > device's driver is responsible for handling the sync state callback. > It'll get the sync_state callback after all the child devices' > consumers have probed. The MFD driver will need to do the sync state > clean up for the children devices or pass it on to the child devices' > drivers (whatever makes sense for that specific MFD) by whatever means > those specific drivers talk to each other (direct calls, registering > callbacks, etc). > > If they are real sub-devices, then they should really be captured in > DT as child devices and then the child device's drivers will get the > sync state callback directly. It seems sort of hand-wavy at the moment. Is the plan to actually implement this for MFDs that are doing these things? It's really hard to understand this patch series without any actual users. >From my perspective using driver probe as the signal that some resource like clks or regulators has been consumed and configured into the proper state is completely wrong. It makes a large assumption that driver probe is actually putting the device into some state that has taken over ownership of the device state by the time probe returns. That isn't always the case when you consider things like the display or GPU don't do much until their device is opened by userspace. It would be better to involve the various kernel frameworks in this decision by having those frameworks intercept the acquisition of the resources they provide and track consumers to the point where we can be certain all consumers have requested and configured the resources they need to operate properly without something go wrong. Maybe we need drivers to indicate this to frameworks somehow so that we don't turn the regulator off for the screen when the screen driver probes but the GPU driver hasn't started drawing anything there because userspace isn't running yet? I'm trying to take a step back and understand the bigger picture here. >From what I can tell we're trying to answer the question "When have all the consumers of this resource put their constraints in place?" This is because we want to actively cleanup resources that have been left on or misconfigured by bootloader/firmware code but we can't be certain when to do that and if we should do that at all. Is that right?
[PATCH] hwmon: (ina3221) Add summation feature support
This patch implements the summation feature of INA3221, mainly the
SCC (enabling) and SF (warning flag) bits of MASK_ENABLE register,
INA3221_SHUNT_SUM (summation of shunt voltages) register, and the
INA3221_CRIT_SUM (its critical alert setting) register.
Although the summation feature allows user to select which channels
to be added to the result, as an initial support, this patch simply
selects all channels by default, with one only condition: all shunt
resistor values need to be the same. This is because the summation
of current channels can be only accurately calculated, using shunt
voltage sum register, if all shunt resistors are equivalent.
Signed-off-by: Nicolin Chen
---
Hi Guenter,
I know my previous questions haven't been answered yet, so nodes
for enabling bits aren't decided completely. But this patch only
adds voltage and its current, and we had a conclusion for these
two already last time. So I think we may add them first. Thanks!
Documentation/hwmon/ina3221.rst | 12 +++
drivers/hwmon/ina3221.c | 163 +++-
2 files changed, 153 insertions(+), 22 deletions(-)
diff --git a/Documentation/hwmon/ina3221.rst b/Documentation/hwmon/ina3221.rst
index f6007ae8f4e2..bf9051339dec 100644
--- a/Documentation/hwmon/ina3221.rst
+++ b/Documentation/hwmon/ina3221.rst
@@ -41,6 +41,18 @@ curr[123]_max Warning alert current(mA) setting,
activates the
average is above this value.
curr[123]_max_alarm Warning alert current limit exceeded
in[456]_input Shunt voltage(uV) for channels 1, 2, and 3 respectively
+in7_input Summation of shunt voltage(uV) channels
+in7_label Channel label for summation of shunt voltage
+curr4_input Summation of current(mA) measurement channels,
+(only available when all channels use the same resistor
+value for their shunt resistors)
+curr4_crit Critical alert current(mA) setting for summation of
+current measurement, activates the corresponding alarm
+when the respective current is above this value
+(only effective when all channels use the same resistor
+value for their shunt resistors)
+curr4_crit_alarmCritical alert current limit exceeded for summation of
+current measurements.
samples Number of samples using in the averaging mode.
Supports the list of number of samples:
diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
index 0037e2bdacd6..0a60d7513037 100644
--- a/drivers/hwmon/ina3221.c
+++ b/drivers/hwmon/ina3221.c
@@ -31,6 +31,8 @@
#define INA3221_WARN2 0x0a
#define INA3221_CRIT3 0x0b
#define INA3221_WARN3 0x0c
+#define INA3221_SHUNT_SUM 0x0d
+#define INA3221_CRIT_SUM 0x0e
#define INA3221_MASK_ENABLE0x0f
#define INA3221_CONFIG_MODE_MASK GENMASK(2, 0)
@@ -50,6 +52,8 @@
#define INA3221_CONFIG_CHs_EN_MASK GENMASK(14, 12)
#define INA3221_CONFIG_CHx_EN(x) BIT(14 - (x))
+#define INA3221_MASK_ENABLE_SCC_MASK GENMASK(14, 12)
+
#define INA3221_CONFIG_DEFAULT 0x7127
#define INA3221_RSHUNT_DEFAULT 1
@@ -60,9 +64,11 @@ enum ina3221_fields {
/* Status Flags */
F_CVRF,
- /* Alert Flags */
+ /* Warning Flags */
F_WF3, F_WF2, F_WF1,
- F_CF3, F_CF2, F_CF1,
+
+ /* Alert Flags: SF is the summation-alert flag */
+ F_SF, F_CF3, F_CF2, F_CF1,
/* sentinel */
F_MAX_FIELDS
@@ -75,6 +81,7 @@ static const struct reg_field ina3221_reg_fields[] = {
[F_WF3] = REG_FIELD(INA3221_MASK_ENABLE, 3, 3),
[F_WF2] = REG_FIELD(INA3221_MASK_ENABLE, 4, 4),
[F_WF1] = REG_FIELD(INA3221_MASK_ENABLE, 5, 5),
+ [F_SF] = REG_FIELD(INA3221_MASK_ENABLE, 6, 6),
[F_CF3] = REG_FIELD(INA3221_MASK_ENABLE, 7, 7),
[F_CF2] = REG_FIELD(INA3221_MASK_ENABLE, 8, 8),
[F_CF1] = REG_FIELD(INA3221_MASK_ENABLE, 9, 9),
@@ -107,6 +114,7 @@ struct ina3221_input {
* @inputs: Array of channel input source specific structures
* @lock: mutex lock to serialize sysfs attribute accesses
* @reg_config: Register value of INA3221_CONFIG
+ * @summation_shunt_resistor: equivalent shunt resistor value for summation
* @single_shot: running in single-shot operating mode
*/
struct ina3221_data {
@@ -116,16 +124,51 @@ struct ina3221_data {
struct ina3221_input inputs[INA3221_NUM_CHANNELS];
struct mutex lock;
u32 reg_config;
+ int summation_shunt_resistor;
bool single_shot;
};
static inline bool ina3221_is_enabled(struct ina3221_data *ina, int channel)
{
+ /* Summation channel checks shunt resistor values */
+ if (channel > INA3221_CHANNEL3)
+ return
Re: [PATCH 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure
On Wed, Oct 16, 2019 at 12:06:51PM +0200, Marco Elver wrote:
> On Wed, 16 Oct 2019 at 11:42, Boqun Feng wrote:
> >
> > Hi Marco,
> >
> > On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
> > [...]
> > > --- /dev/null
> > > +++ b/kernel/kcsan/kcsan.c
> > > @@ -0,0 +1,81 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +
> > > +/*
> > > + * The Kernel Concurrency Sanitizer (KCSAN) infrastructure. For more
> > > info please
> > > + * see Documentation/dev-tools/kcsan.rst.
> > > + */
> > > +
> > > +#include
> > > +
> > > +#include "kcsan.h"
> > > +
> > > +/*
> > > + * Concurrency Sanitizer uses the same instrumentation as Thread
> > > Sanitizer.
> >
> > Is there any documentation on the instrumentation? Like a complete list
> > for all instrumentation functions plus a description of where the
> > compiler will use those functions. Yes, the names of the below functions
> > are straightforward, but an accurate doc on the instrumentation will
> > cerntainly help people review KCSAN.
>
> As far as I'm aware neither GCC nor Clang have documentation on the
> emitted instrumentation that we could reference (other than look into
> the compiler passes).
>
Yeah, I don't find them either, which makes me surprised, because I
think the thread sanitizer has been there for a while...
> However it is as straightforward as it seems: the compiler emits
> instrumentation calls for all loads and stores that the compiler
> generates; inline asm is not instrumented. I will add a comment to
> that effect for v2.
>
Or you can push the compiler people to document it, and we can simply
reference it in kernel ;-)
Regards,
Boqun
> Thanks,
> -- Marco
>
> > Regards,
> > Boqun
> >
> > > + */
> > > +
> > > +#define DEFINE_TSAN_READ_WRITE(size)
> > > \
> > > + void __tsan_read##size(void *ptr)
> > >\
> > > + {
> > >\
> > > + __kcsan_check_access(ptr, size, false);
> > >\
> > > + }
> > >\
> > > + EXPORT_SYMBOL(__tsan_read##size);
> > >\
> > > + void __tsan_write##size(void *ptr)
> > >\
> > > + {
> > >\
> > > + __kcsan_check_access(ptr, size, true);
> > >\
> > > + }
> > >\
> > > + EXPORT_SYMBOL(__tsan_write##size)
> > > +
> > > +DEFINE_TSAN_READ_WRITE(1);
> > > +DEFINE_TSAN_READ_WRITE(2);
> > > +DEFINE_TSAN_READ_WRITE(4);
> > > +DEFINE_TSAN_READ_WRITE(8);
> > > +DEFINE_TSAN_READ_WRITE(16);
> > > +
> > > +/*
> > > + * Not all supported compiler versions distinguish aligned/unaligned
> > > accesses,
> > > + * but e.g. recent versions of Clang do.
> > > + */
> > > +#define DEFINE_TSAN_UNALIGNED_READ_WRITE(size)
> > > \
> > > + void __tsan_unaligned_read##size(void *ptr)
> > >\
> > > + {
> > >\
> > > + __kcsan_check_access(ptr, size, false);
> > >\
> > > + }
> > >\
> > > + EXPORT_SYMBOL(__tsan_unaligned_read##size);
> > >\
> > > + void __tsan_unaligned_write##size(void *ptr)
> > >\
> > > + {
> > >\
> > > + __kcsan_check_access(ptr, size, true);
> > >\
> > > + }
> > >\
> > > + EXPORT_SYMBOL(__tsan_unaligned_write##size)
> > > +
> > > +DEFINE_TSAN_UNALIGNED_READ_WRITE(2);
> > > +DEFINE_TSAN_UNALIGNED_READ_WRITE(4);
> > > +DEFINE_TSAN_UNALIGNED_READ_WRITE(8);
> > > +DEFINE_TSAN_UNALIGNED_READ_WRITE(16);
> > > +
> > > +void __tsan_read_range(void *ptr, size_t size)
> > > +{
> > > + __kcsan_check_access(ptr, size, false);
> > > +}
> > > +EXPORT_SYMBOL(__tsan_read_range);
> > > +
> > > +void __tsan_write_range(void *ptr, size_t size)
> > > +{
> > > + __kcsan_check_access(ptr, size, true);
> > > +}
> > > +EXPORT_SYMBOL(__tsan_write_range);
> > > +
> > > +/*
> > > + * The below are not required KCSAN, but can still be emitted by the
> > > compiler.
> > > + */
> > > +void __tsan_func_entry(void *call_pc)
> > > +{
> > > +}
> > > +EXPORT_SYMBOL(__tsan_func_entry);
> > > +void __tsan_func_exit(void)
> > > +{
> > > +}
> > > +EXPORT_SYMBOL(__tsan_func_exit);
> > > +void __tsan_init(void)
> > > +{
> > > +}
> > > +EXPORT_SYMBOL(__tsan_init);
> > [...]
signature.asc
Description: PGP sign
Re: [PATCH 26/34] Documentation/RCU: Use CONFIG_PREEMPTION where appropriate
On Wed, Oct 16, 2019 at 09:31:32AM +0200, Sebastian Andrzej Siewior wrote: > On 2019-10-15 21:13:30 [-0700], Paul E. McKenney wrote: > > Sadly, this one ran afoul of the .txt-to-.rst migration. Even applying > > it against linus/master and cherry-picking it does not help. I will > > defer it for the moment -- perhaps Mauro or Joel have some advice. > > Don't worry about it then. Just point me to the tree once it is done. Thank you very much and will do! Thanx, Paul
