Re: [PATCH 3/5] ASoC: mediatek: Add MT8516 PCM driver
On Thu, May 02, 2019 at 02:10:39PM +0200, Fabien Parent wrote:
> +static irqreturn_t mt8516_afe_irq_handler(int irq, void *dev_id)
> +{
> + struct mtk_base_afe *afe = dev_id;
> + unsigned int reg_value;
> + unsigned int memif_status;
> + int i, ret;
> +
> + ret = regmap_read(afe->regmap, AFE_IRQ_STATUS, _value);
> + if (ret) {
> + reg_value = AFE_IRQ_STATUS_BITS;
> + goto exit_irq;
> + }
...
> +exit_irq:
> + regmap_write(afe->regmap, AFE_IRQ_CLR, reg_value & AFE_IRQ_STATUS_BITS);
> +
> + return IRQ_HANDLED;
> +}
This unconditionally says it handled an interrupt regardless of what
happened. This means that the interrupt line can't be shared and that
the error handling code in the generic interrupt subsystem can't tell if
something goes wrong and the interrupt gets stuck.
> + ret = devm_request_irq(afe->dev, irq_id, mt8516_afe_irq_handler,
> +0, "Afe_ISR_Handle", (void *)afe);
> + if (ret) {
> + dev_err(afe->dev, "could not request_irq\n");
> + return ret;
> + }
Are you sure the interrupt handler can safely use managed resources,
especially given...
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + afe->base_addr = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(afe->base_addr))
> + return PTR_ERR(afe->base_addr);
> +
> + afe->regmap = devm_regmap_init_mmio(>dev, afe->base_addr,
> + _afe_regmap_config);
> + if (IS_ERR(afe->regmap))
> + return PTR_ERR(afe->regmap);
...that things like the register map and the I/O resources for the chip
are allocated after and therefore freed before before the interrupt is
freed. Normally the interrupt should be one of the last things to be
allocated.
> +static int mt8516_afe_pcm_dev_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
In general if functions can legitimately be empty they should just be
omitted, if they are required that usually means they have to do
something.
signature.asc
Description: PGP signature
[tip:perf/urgent] tools arch uapi: Copy missing unistd.h headers for arc, hexagon and riscv
Commit-ID: 18f90d372cf35b387663f1567de701e5393f6eb5
Gitweb: https://git.kernel.org/tip/18f90d372cf35b387663f1567de701e5393f6eb5
Author: Arnaldo Carvalho de Melo
AuthorDate: Mon, 22 Apr 2019 15:21:35 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 2 May 2019 16:00:20 -0400
tools arch uapi: Copy missing unistd.h headers for arc, hexagon and riscv
Since those were introduced in:
c8ce48f06503 ("asm-generic: Make time32 syscall numbers optional")
But when the asm-generic/unistd.h was sync'ed with tools/ in:
1a787fc5ba18 ("tools headers uapi: Sync copy of asm-generic/unistd.h with the
kernel sources")
I forgot to copy the files for the architectures that define
__ARCH_WANT_TIME32_SYSCALLS, so the perf build was breaking there, as
reported by Vineet Gupta for the ARC architecture.
After updating my ARC container to use the glibc based toolchain + cross
building libnuma, zlib and elfutils, I finally managed to reproduce the
problem and verify that this now is fixed and will not regress as will
be tested before each pull req sent upstream.
Reported-by: Vineet Gupta
Cc: Adrian Hunter
Cc: Arnd Bergmann
Cc: Jiri Olsa
CC: linux-snps-...@lists.infradead.org
Cc: Namhyung Kim
Link: https://lkml.kernel.org/r/20190426193531.gc28...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
{arch => tools/arch}/arc/include/uapi/asm/unistd.h | 0
{arch => tools/arch}/hexagon/include/uapi/asm/unistd.h | 0
{arch => tools/arch}/riscv/include/uapi/asm/unistd.h | 0
3 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/arch/arc/include/uapi/asm/unistd.h
b/tools/arch/arc/include/uapi/asm/unistd.h
similarity index 100%
copy from arch/arc/include/uapi/asm/unistd.h
copy to tools/arch/arc/include/uapi/asm/unistd.h
diff --git a/arch/hexagon/include/uapi/asm/unistd.h
b/tools/arch/hexagon/include/uapi/asm/unistd.h
similarity index 100%
copy from arch/hexagon/include/uapi/asm/unistd.h
copy to tools/arch/hexagon/include/uapi/asm/unistd.h
diff --git a/arch/riscv/include/uapi/asm/unistd.h
b/tools/arch/riscv/include/uapi/asm/unistd.h
similarity index 100%
copy from arch/riscv/include/uapi/asm/unistd.h
copy to tools/arch/riscv/include/uapi/asm/unistd.h
[tip:perf/urgent] perf tools: Remove needless asm/unistd.h include fixing build in some places
Commit-ID: 7e221b811f1472d0c58c7d4e0fe84fcacd22580a Gitweb: https://git.kernel.org/tip/7e221b811f1472d0c58c7d4e0fe84fcacd22580a Author: Arnaldo Carvalho de Melo AuthorDate: Thu, 2 May 2019 09:26:23 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 2 May 2019 16:00:20 -0400 perf tools: Remove needless asm/unistd.h include fixing build in some places We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h includes asm/unistd.h, sometimes this leads to the redefinition of defines, breaking the build. Noticed on ARC with uCLibc. Cc: Adrian Hunter Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Jiri Olsa Cc: Namhyung Kim Cc: Rich Felker Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-xjpf80o64i2ko74aj2jih...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/cloexec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c index ca0fff6272be..06f48312c5ed 100644 --- a/tools/perf/util/cloexec.c +++ b/tools/perf/util/cloexec.c @@ -7,7 +7,6 @@ #include "asm/bug.h" #include "debug.h" #include -#include #include static unsigned long flag = PERF_FLAG_FD_CLOEXEC;
[tip:perf/urgent] tools build: Add -ldl to the disassembler-four-args feature test
Commit-ID: c638417e1a64b1f43ebab589e697d1cd1a127a74 Gitweb: https://git.kernel.org/tip/c638417e1a64b1f43ebab589e697d1cd1a127a74 Author: Arnaldo Carvalho de Melo AuthorDate: Wed, 1 May 2019 16:27:00 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 2 May 2019 16:00:20 -0400 tools build: Add -ldl to the disassembler-four-args feature test Thomas Backlund reported that the perf build was failing on the Mageia 7 distro, that is because it uses: cat /tmp/build/perf/feature/test-disassembler-four-args.make.output /usr/bin/ld: /usr/lib64/libbfd.a(plugin.o): in function `try_load_plugin': /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:243: undefined reference to `dlopen' /usr/bin/ld: /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:271: undefined reference to `dlsym' /usr/bin/ld: /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:256: undefined reference to `dlclose' /usr/bin/ld: /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:246: undefined reference to `dlerror' as we allow dynamic linking and loading Mageia 7 uses these linker flags: $ rpm --eval %ldflags -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags So add -ldl to this feature LDFLAGS. Reported-by: Thomas Backlund Tested-by: Thomas Backlund Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Cc: Song Liu Link: https://lkml.kernel.org/r/20190501173158.gc21...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index fe3f97e342fa..6d65874e16c3 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -227,7 +227,7 @@ FEATURE_CHECK_LDFLAGS-libpython-version := $(PYTHON_EMBED_LDOPTS) FEATURE_CHECK_LDFLAGS-libaio = -lrt -FEATURE_CHECK_LDFLAGS-disassembler-four-args = -lbfd -lopcodes +FEATURE_CHECK_LDFLAGS-disassembler-four-args = -lbfd -lopcodes -ldl CFLAGS += -fno-omit-frame-pointer CFLAGS += -ggdb3
[tip:perf/urgent] perf cs-etm: Always allocate memory for cs_etm_queue::prev_packet
Commit-ID: 35bb59c10a6d0578806dd500477dae9cb4be344e
Gitweb: https://git.kernel.org/tip/35bb59c10a6d0578806dd500477dae9cb4be344e
Author: Leo Yan
AuthorDate: Sun, 28 Apr 2019 16:32:27 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 2 May 2019 16:00:20 -0400
perf cs-etm: Always allocate memory for cs_etm_queue::prev_packet
Robert Walker reported a segmentation fault is observed when process
CoreSight trace data; this issue can be easily reproduced by the command
'perf report --itrace=i1000i' for decoding tracing data.
If neither the 'b' flag (synthesize branches events) nor 'l' flag
(synthesize last branch entries) are specified to option '--itrace',
cs_etm_queue::prev_packet will not been initialised. After merging the
code to support exception packets and sample flags, there introduced a
number of uses of cs_etm_queue::prev_packet without checking whether it
is valid, for these cases any accessing to uninitialised prev_packet
will cause crash.
As cs_etm_queue::prev_packet is used more widely now and it's already
hard to follow which functions have been called in a context where the
validity of cs_etm_queue::prev_packet has been checked, this patch
always allocates memory for cs_etm_queue::prev_packet.
Reported-by: Robert Walker
Suggested-by: Robert Walker
Signed-off-by: Leo Yan
Tested-by: Robert Walker
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Namhyung Kim
Cc: Suzuki K Poulouse
Cc: linux-arm-ker...@lists.infradead.org
Fixes: 7100b12cf474 ("perf cs-etm: Generate branch sample for exception packet")
Fixes: 24fff5eb2b93 ("perf cs-etm: Avoid stale branch samples when flush
packet")
Link: http://lkml.kernel.org/r/20190428083228.20246-1-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/cs-etm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index cfc1ad8c..de488b43f440 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -422,11 +422,9 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct
cs_etm_auxtrace *etm)
if (!etmq->packet)
goto out_free;
- if (etm->synth_opts.last_branch || etm->sample_branches) {
- etmq->prev_packet = zalloc(szp);
- if (!etmq->prev_packet)
- goto out_free;
- }
+ etmq->prev_packet = zalloc(szp);
+ if (!etmq->prev_packet)
+ goto out_free;
if (etm->synth_opts.last_branch) {
size_t sz = sizeof(struct branch_stack);
[tip:perf/urgent] perf cs-etm: Don't check cs_etm_queue::prev_packet validity
Commit-ID: cf0c37b6dbf74fb71bea07b516612d29e00dcbc4
Gitweb: https://git.kernel.org/tip/cf0c37b6dbf74fb71bea07b516612d29e00dcbc4
Author: Leo Yan
AuthorDate: Sun, 28 Apr 2019 16:32:28 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 2 May 2019 16:00:20 -0400
perf cs-etm: Don't check cs_etm_queue::prev_packet validity
Since cs_etm_queue::prev_packet is allocated for all cases, it will
never be NULL pointer; now validity checking prev_packet is pointless,
remove all of them.
Signed-off-by: Leo Yan
Tested-by: Robert Walker
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Namhyung Kim
Cc: Suzuki K Poulouse
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20190428083228.20246-2-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/cs-etm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 110804936fc3..cfc1ad8c 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -981,7 +981,6 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
* PREV_PACKET is a branch.
*/
if (etm->synth_opts.last_branch &&
- etmq->prev_packet &&
etmq->prev_packet->sample_type == CS_ETM_RANGE &&
etmq->prev_packet->last_instr_taken_branch)
cs_etm__update_last_branch_rb(etmq);
@@ -1014,7 +1013,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
etmq->period_instructions = instrs_over;
}
- if (etm->sample_branches && etmq->prev_packet) {
+ if (etm->sample_branches) {
bool generate_sample = false;
/* Generate sample for tracing on packet */
@@ -1071,9 +1070,6 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
struct cs_etm_auxtrace *etm = etmq->etm;
struct cs_etm_packet *tmp;
- if (!etmq->prev_packet)
- return 0;
-
/* Handle start tracing packet */
if (etmq->prev_packet->sample_type == CS_ETM_EMPTY)
goto swap_packet;
[tip:perf/urgent] perf report: Report OOM in status line in the GTK UI
Commit-ID: 167e418fa0871c083e2c74508d73012abb01e6f7
Gitweb: https://git.kernel.org/tip/167e418fa0871c083e2c74508d73012abb01e6f7
Author: Thomas Richter
AuthorDate: Tue, 23 Apr 2019 12:53:03 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 2 May 2019 16:00:20 -0400
perf report: Report OOM in status line in the GTK UI
An -ENOMEM error is not reported in the GTK GUI. Instead this error
message pops up on the screen:
[root@m35lp76 perf]# ./perf report -i perf.data.error68-1
Processing events... [974K/3M]
Error:failed to process sample
0xf4198 [0x8]: failed to process type: 68
However when I use the same perf.data file with --stdio it works:
[root@m35lp76 perf]# ./perf report -i perf.data.error68-1 --stdio \
| head -12
# Total Lost Samples: 0
#
# Samples: 76K of event 'cycles'
# Event count (approx.): 9905616
#
# Overhead Command Shared Object Symbol
# ... . .
#
8.81% find [kernel.kallsyms] [k] ftrace_likely_update
8.74% swapper [kernel.kallsyms] [k] ftrace_likely_update
8.34% sshd [kernel.kallsyms] [k] ftrace_likely_update
2.19% kworker/u512:1- [kernel.kallsyms] [k] ftrace_likely_update
The sample precentage is a bit low.
The GUI always fails in the FINISHED_ROUND event (68) and does not
indicate the reason why.
When happened is the following. Perf report calls a lot of functions and
down deep when a FINISHED_ROUND event is processed, these functions are
called:
perf_session__process_event()
+ perf_session__process_user_event()
+ process_finished_round()
+ ordered_events__flush()
+ __ordered_events__flush()
+ do_flush()
+ ordered_events__deliver_event()
+ perf_session__deliver_event()
+ machine__deliver_event()
+ perf_evlist__deliver_event()
+ process_sample_event()
+ hist_entry_iter_add() --> only called in GUI case!!!
+ hist_iter__report__callback()
+ symbol__inc_addr_sample()
Now this functions runs out of memory and
returns -ENOMEM. This is reported all the way up
until function
perf_session__process_event() returns to its caller, where -ENOMEM is
changed to -EINVAL and processing stops:
if ((skip = perf_session__process_event(session, event, head)) < 0) {
pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
head, event->header.size, event->header.type);
err = -EINVAL;
goto out_err;
}
This occurred in the FINISHED_ROUND event when it has to process some
1 entries and ran out of memory.
This patch indicates the root cause and displays it in the status line
of ther perf report GUI.
Output before (on GUI status line):
0xf4198 [0x8]: failed to process type: 68
Output after:
0xf4198 [0x8]: failed to process type: 68 [not enough memory]
Committer notes:
the 'skip' variable needs to be initialized to -EINVAL, so that when the
size is less than sizeof(struct perf_event_attr) we avoid this valid
compiler warning:
util/session.c: In function ‘perf_session__process_events’:
util/session.c:1936:7: error: ‘skip’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
err = skip;
^~
util/session.c:1874:6: note: ‘skip’ was declared here
s64 skip;
^~~~
cc1: all warnings being treated as errors
Signed-off-by: Thomas Richter
Reviewed-by: Hendrik Brueckner
Reviewed-by: Jiri Olsa
Cc: Heiko Carstens
Cc: Martin Schwidefsky
Link: http://lkml.kernel.org/r/20190423105303.61683-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/session.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index b17f1c9bc965..bad5f87ae001 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1928,12 +1928,14 @@ more:
size = event->header.size;
+ skip = -EINVAL;
+
if (size < sizeof(struct perf_event_header) ||
(skip = rd->process(session, event, file_pos)) < 0) {
- pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
+ pr_err("%#" PRIx64 " [%#x]: failed to process type: %d [%s]\n",
file_offset + head, event->header.size,
- event->header.type);
- err = -EINVAL;
+ event->header.type, strerror(-skip));
+ err = skip;
goto out;
}
[tip:perf/urgent] tools uapi x86: Sync vmx.h with the kernel
Commit-ID: 24e45b49eef07814e0507507161cd06f15b8ee1b
Gitweb: https://git.kernel.org/tip/24e45b49eef07814e0507507161cd06f15b8ee1b
Author: Arnaldo Carvalho de Melo
AuthorDate: Mon, 22 Apr 2019 11:54:50 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 2 May 2019 16:00:19 -0400
tools uapi x86: Sync vmx.h with the kernel
To pick up the changes from:
2b27924bb1d4 ("KVM: nVMX: always use early vmcs check when EPT is disabled")
That causes this object in the tools/perf build process to be rebuilt:
CC /tmp/build/perf/arch/x86/util/kvm-stat.o
But it isn't using VMX_ABORT_ prefixed constants, so no change in
behaviour.
This silences this perf build warning:
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' differs
from latest version at 'arch/x86/include/uapi/asm/vmx.h'
diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paolo Bonzini
Link: https://lkml.kernel.org/n/tip-bjbo3zc0r8i8oa0udpvft...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/arch/x86/include/uapi/asm/vmx.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/arch/x86/include/uapi/asm/vmx.h
b/tools/arch/x86/include/uapi/asm/vmx.h
index f0b0c90dd398..d213ec5c3766 100644
--- a/tools/arch/x86/include/uapi/asm/vmx.h
+++ b/tools/arch/x86/include/uapi/asm/vmx.h
@@ -146,6 +146,7 @@
#define VMX_ABORT_SAVE_GUEST_MSR_FAIL1
#define VMX_ABORT_LOAD_HOST_PDPTE_FAIL 2
+#define VMX_ABORT_VMCS_CORRUPTED 3
#define VMX_ABORT_LOAD_HOST_MSR_FAIL 4
#endif /* _UAPIVMX_H */
[tip:perf/urgent] perf bpf: Return value with unlocking in perf_env__find_btf()
Commit-ID: 2e712675ffd1331bb527dfc851b0e98cd684c2f1 Gitweb: https://git.kernel.org/tip/2e712675ffd1331bb527dfc851b0e98cd684c2f1 Author: Bo YU AuthorDate: Mon, 22 Apr 2019 04:01:38 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 2 May 2019 16:00:19 -0400 perf bpf: Return value with unlocking in perf_env__find_btf() In perf_env__find_btf(), we're returning without unlocking "env->bpf_progs.lock". There may be cause lockdep issue. Detected by CoversityScan, CID# 1444762:(program hangs(LOCK)) Signed-off-by: Bo YU Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Yonghong Song Cc: b...@vger.kernel.org Cc: net...@vger.kernel.org Fixes: 2db7b1e0bd49d: (perf bpf: Return NULL when RB tree lookup fails in perf_env__find_btf()) Link: http://lkml.kernel.org/r/20190422080138.10088-1-tsu.y...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/env.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c index 9494f9dc61ec..6a3eaf7d9353 100644 --- a/tools/perf/util/env.c +++ b/tools/perf/util/env.c @@ -115,8 +115,8 @@ struct btf_node *perf_env__find_btf(struct perf_env *env, __u32 btf_id) } node = NULL; - up_read(>bpf_progs.lock); out: + up_read(>bpf_progs.lock); return node; }
[tip:perf/urgent] tools lib traceevent: Change tag string for error
Commit-ID: 5f05182fab9a29fea6c4ab8113be45adf0c11bf0
Gitweb: https://git.kernel.org/tip/5f05182fab9a29fea6c4ab8113be45adf0c11bf0
Author: Leo Yan
AuthorDate: Wed, 24 Apr 2019 09:38:02 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 2 May 2019 16:00:19 -0400
tools lib traceevent: Change tag string for error
The traceevent lib is used by the perf tool, and when executing
perf test -v 6
it outputs error log on the ARM64 platform:
running test 33 '*:*'trace-cmd: No such file or directory
[...]
trace-cmd: Invalid argument
The trace event parsing code originally came from trace-cmd so it keeps
the tag string "trace-cmd" for errors, this easily introduces the
impression that the perf tool launches trace-cmd command for trace event
parsing, but in fact the related parsing is accomplished by the
traceevent lib.
This patch changes the tag string to "libtraceevent" so that we can
avoid confusion and let users to more easily connect the error with
traceevent lib.
Signed-off-by: Leo Yan
Acked-by: Steven Rostedt (VMware)
Link: http://lkml.kernel.org/r/20190424013802.27569-1-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/parse-utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/traceevent/parse-utils.c
b/tools/lib/traceevent/parse-utils.c
index 77e4ec6402dd..e99867111387 100644
--- a/tools/lib/traceevent/parse-utils.c
+++ b/tools/lib/traceevent/parse-utils.c
@@ -14,7 +14,7 @@
void __vwarning(const char *fmt, va_list ap)
{
if (errno)
- perror("trace-cmd");
+ perror("libtraceevent");
errno = 0;
fprintf(stderr, " ");
[tip:perf/urgent] perf bench numa: Add define for RUSAGE_THREAD if not present
Commit-ID: bf561d3c13423fc54daa19b5d49dc15fafdb7acc Gitweb: https://git.kernel.org/tip/bf561d3c13423fc54daa19b5d49dc15fafdb7acc Author: Arnaldo Carvalho de Melo AuthorDate: Thu, 25 Apr 2019 18:36:51 -0300 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 2 May 2019 16:00:20 -0400 perf bench numa: Add define for RUSAGE_THREAD if not present While cross building perf to the ARC architecture on a fedora 30 host, we were failing with: CC /tmp/build/perf/bench/numa.o bench/numa.c: In function ‘worker_thread’: bench/numa.c:1261:12: error: ‘RUSAGE_THREAD’ undeclared (first use in this function); did you mean ‘SIGEV_THREAD’? getrusage(RUSAGE_THREAD, ); ^ SIGEV_THREAD bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in [perfbuilder@60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1 arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225 [perfbuilder@60d5802468f6 perf]$ Trying to reproduce a report by Vineet, I noticed that, with just cross-built zlib and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define, check for that and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define in the system headers, check if it is defined in the 'perf bench numa' sources and define it if not. Now it builds and I have to figure out if the problem reported by Vineet only takes place if we have libelf or some other library available. Cc: Arnd Bergmann Cc: Jiri Olsa Cc: linux-snps-...@lists.infradead.org Cc: Namhyung Kim Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/bench/numa.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c index 98ad783efc69..a7784554a80d 100644 --- a/tools/perf/bench/numa.c +++ b/tools/perf/bench/numa.c @@ -39,6 +39,10 @@ #include #include +#ifndef RUSAGE_THREAD +# define RUSAGE_THREAD 1 +#endif + /* * Regular printout to the terminal, supressed if -q is specified: */
[tip:perf/urgent] perf annotate: Fix build on 32 bit for BPF annotation
Commit-ID: 01e985e900d3e602e9b1a55372a8e5274012a417
Gitweb: https://git.kernel.org/tip/01e985e900d3e602e9b1a55372a8e5274012a417
Author: Thadeu Lima de Souza Cascardo
AuthorDate: Wed, 3 Apr 2019 16:44:52 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 2 May 2019 16:00:19 -0400
perf annotate: Fix build on 32 bit for BPF annotation
Commit 6987561c9e86 ("perf annotate: Enable annotation of BPF programs") adds
support for BPF programs annotations but the new code does not build on 32-bit.
Signed-off-by: Thadeu Lima de Souza Cascardo
Acked-by: Song Liu
Fixes: 6987561c9e86 ("perf annotate: Enable annotation of BPF programs")
Link: http://lkml.kernel.org/r/20190403194452.10845-1-casca...@canonical.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/annotate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index c8b01176c9e1..09762985c713 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1714,8 +1714,8 @@ static int symbol__disassemble_bpf(struct symbol *sym,
if (dso->binary_type != DSO_BINARY_TYPE__BPF_PROG_INFO)
return -1;
- pr_debug("%s: handling sym %s addr %lx len %lx\n", __func__,
-sym->name, sym->start, sym->end - sym->start);
+ pr_debug("%s: handling sym %s addr %" PRIx64 " len %" PRIx64 "\n",
__func__,
+ sym->name, sym->start, sym->end - sym->start);
memset(tpath, 0, sizeof(tpath));
perf_exe(tpath, sizeof(tpath));
@@ -1740,7 +1740,7 @@ static int symbol__disassemble_bpf(struct symbol *sym,
info_linear = info_node->info_linear;
sub_id = dso->bpf_prog.sub_id;
- info.buffer = (void *)(info_linear->info.jited_prog_insns);
+ info.buffer = (void *)(uintptr_t)(info_linear->info.jited_prog_insns);
info.buffer_length = info_linear->info.jited_prog_len;
if (info_linear->info.nr_line_info)
@@ -1776,7 +1776,7 @@ static int symbol__disassemble_bpf(struct symbol *sym,
const char *srcline;
u64 addr;
- addr = pc + ((u64 *)(info_linear->info.jited_ksyms))[sub_id];
+ addr = pc + ((u64
*)(uintptr_t)(info_linear->info.jited_ksyms))[sub_id];
count = disassemble(pc, );
if (prog_linfo)
Re: [GIT PULL 00/11] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > This took a bit more time than I expected as I'm traveling, > LSF/MM + BPF, and also some of the fixes I worked on and off while on my > way here needed tweaks, > > Thanks, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 1804569d87de903b4d746ba71512c3ed0a890d65: > > MAINTAINERS: Include vendor specific files under arch/*/events/* > (2019-05-02 18:28:12 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-5.1-20190502 > > for you to fetch changes up to 7e221b811f1472d0c58c7d4e0fe84fcacd22580a: > > perf tools: Remove needless asm/unistd.h include fixing build in some > places (2019-05-02 16:00:20 -0400) > > > perf/urgent fixes: > > tools UAPI: > > Arnaldo Carvalho de Melo: > > - Sync x86's vmx.h with the kernel. > > - Copy missing unistd.h headers for arc, hexagon and riscv, fixing > a reported build regression on the ARC 32-bit architecture. > > perf bench numa: > > Arnaldo Carvalho de Melo: > > - Add define for RUSAGE_THREAD if not present, fixing the build on the > ARC architecture when only zlib and libnuma are present. > > perf BPF: > > Arnaldo Carvalho de Melo: > > - The disassembler-four-args feature test needs -ldl on distros such as > Mageia 7. > > Bo YU: > > - Fix unlocking on success in perf_env__find_btf(), detected with > the coverity tool. > > libtraceevent: > > Leo Yan: > > - Change misleading hard coded 'trace-cmd' string in error messages. > > ARM hardware tracing: > > Leo Yan: > > - Always allocate memory for cs_etm_queue::prev_packet, fixing a segfault > when processing CoreSight perf data. > > perf annotate: > > Thadeu Lima de Souza Cascardo: > > - Fix build on 32 bit for BPF. > > perf report: > > Thomas Richter: > > - Report OOM in status line in the GTK UI. > > core libs: > > - Remove needless asm/unistd.h that, used with sys/syscall.h ended > up redefining the syscalls defines in environments such as the > ARC arch when using uClibc. > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (5): > tools uapi x86: Sync vmx.h with the kernel > perf bench numa: Add define for RUSAGE_THREAD if not present > tools build: Add -ldl to the disassembler-four-args feature test > tools arch uapi: Copy missing unistd.h headers for arc, hexagon and > riscv > perf tools: Remove needless asm/unistd.h include fixing build in some > places > > Bo YU (1): > perf bpf: Return value with unlocking in perf_env__find_btf() > > Leo Yan (3): > tools lib traceevent: Change tag string for error > perf cs-etm: Don't check cs_etm_queue::prev_packet validity > perf cs-etm: Always allocate memory for cs_etm_queue::prev_packet > > Thadeu Lima de Souza Cascardo (1): > perf annotate: Fix build on 32 bit for BPF annotation > > Thomas Richter (1): > perf report: Report OOM in status line in the GTK UI > > tools/arch/arc/include/uapi/asm/unistd.h | 51 > > tools/arch/hexagon/include/uapi/asm/unistd.h | 40 ++ > tools/arch/riscv/include/uapi/asm/unistd.h | 42 +++ > tools/arch/x86/include/uapi/asm/vmx.h| 1 + > tools/lib/traceevent/parse-utils.c | 2 +- > tools/perf/Makefile.config | 2 +- > tools/perf/bench/numa.c | 4 +++ > tools/perf/util/annotate.c | 8 ++--- > tools/perf/util/cloexec.c| 1 - > tools/perf/util/cs-etm.c | 14 +++- > tools/perf/util/env.c| 2 +- > tools/perf/util/session.c| 8 +++-- > 12 files changed, 154 insertions(+), 21 deletions(-) > create mode 100644 tools/arch/arc/include/uapi/asm/unistd.h > create mode 100644 tools/arch/hexagon/include/uapi/asm/unistd.h > create mode 100644 tools/arch/riscv/include/uapi/asm/unistd.h Pulled, thanks a lot Arnaldo! Ingo
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
On Thu, May 2, 2019 at 6:45 PM Frank Rowand wrote: > > On 5/2/19 4:45 PM, Brendan Higgins wrote: > > On Thu, May 2, 2019 at 2:16 PM Frank Rowand wrote: > >> > >> On 5/2/19 11:07 AM, Brendan Higgins wrote: > >>> On Thu, May 2, 2019 at 4:02 AM Greg KH wrote: > > On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: > > From: Felix Guo > > > > The ultimate goal is to create minimal isolated test binaries; in the > > meantime we are using UML to provide the infrastructure to run tests, so > > define an abstract way to configure and run tests that allow us to > > change the context in which tests are built without affecting the user. > > This also makes pretty and dynamic error reporting, and a lot of other > > nice features easier. > > > > kunit_config.py: > > - parse .config and Kconfig files. > > > > kunit_kernel.py: provides helper functions to: > > - configure the kernel using kunitconfig. > > - build the kernel with the appropriate configuration. > > - provide function to invoke the kernel and stream the output back. > > > > Signed-off-by: Felix Guo > > Signed-off-by: Brendan Higgins > > Ah, here's probably my answer to my previous logging format question, > right? What's the chance that these wrappers output stuff in a standard > format that test-framework-tools can already parse? :) > > > > To be clear, the test-framework-tools format we are talking about is > > TAP13[1], correct? > > I'm not sure what the test community prefers for a format. I'll let them > jump in and debate that question. > > > > > > My understanding is that is what kselftest is being converted to use. > > > >>> > >>> It should be pretty easy to do. I had some patches that pack up the > >>> results into a serialized format for a presubmit service; it should be > >>> pretty straightforward to take the same logic and just change the > >>> output format. > >> > >> When examining and trying out the previous versions of the patch I found > >> the wrappers useful to provide information about how to control and use > >> the tests, but I had no interest in using the scripts as they do not > >> fit in with my personal environment and workflow. > >> > >> In the previous versions of the patch, these helper scripts are optional, > >> which is good for my use case. If the helper scripts are required to > > > > They are still optional. > > > >> get the data into the proper format then the scripts are not quite so > >> optional, they become the expected environment. I think the proper > >> format should exist without the helper scripts. > > > > That's a good point. A couple things, > > > > First off, supporting TAP13, either in the kernel or the wrapper > > script is not hard, but I don't think that is the real issue that you > > raise. > > > > If your only concern is that you will always be able to have human > > readable KUnit results printed to the kernel log, that is a guarantee > > I feel comfortable making. Beyond that, I think it is going to take a > > long while before I would feel comfortable guaranteeing anything about > > how will KUnit work, what kind of data it will want to expose, and how > > it will be organized. I think the wrapper script provides a nice > > facade that I can maintain, can mediate between the implementation > > details and the user, and can mediate between the implementation > > details and other pieces of software that might want to consume > > results. > > > > [1] https://testanything.org/tap-version-13-specification.html > > My concern is based on a focus on my little part of the world > (which in _previous_ versions of the patch series was the devicetree > unittest.c tests being converted to use the kunit infrastructure). > If I step back and think of the entire kernel globally I may end > up with a different conclusion - but I'm going to remain myopic > for this email. > > I want the test results to be usable by me and my fellow > developers. I prefer that the test results be easily accessible > (current printk() implementation means that kunit messages are > just as accessible as the current unittest.c printk() output). > If the printk() output needs to be filtered through a script > to generate the actual test results then that is sub-optimal > to me. It is one more step added to my workflow. And > potentially with an embedded target a major pain to get a > data file (the kernel log file) transferred from a target > to my development host. That's fair. If that is indeed your only concern, then I don't think the wrapper script will ever be an issue for you. You will always be able to execute a given test the old fashioned/manual way, and the wrapper script only summarizes results, it does not change the contents. > > I want a reported test failure to be easy to trace back to the > point in the source where the failure is reported. With printk() > the search is a simple
[PATCH 2/2] regulator: da9xxx: Switch to SPDX identifier
Convert Dialog Semiconductor DA9xxx regulator drivers to SPDX identifier. Signed-off-by: Axel Lin --- drivers/regulator/da903x.c | 16 ++-- drivers/regulator/da9052-regulator.c | 20 +++- drivers/regulator/da9055-regulator.c | 20 +++- drivers/regulator/da9062-regulator.c | 19 +-- drivers/regulator/da9210-regulator.c | 23 --- drivers/regulator/da9210-regulator.h | 17 + drivers/regulator/da9211-regulator.c | 20 +--- drivers/regulator/da9211-regulator.h | 11 +-- 8 files changed, 36 insertions(+), 110 deletions(-) diff --git a/drivers/regulator/da903x.c b/drivers/regulator/da903x.c index 33e8f3b8d2bd..5493c3a86426 100644 --- a/drivers/regulator/da903x.c +++ b/drivers/regulator/da903x.c @@ -1,13 +1,9 @@ -/* - * Regulators driver for Dialog Semiconductor DA903x - * - * Copyright (C) 2006-2008 Marvell International Ltd. - * Copyright (C) 2008 Compulab Ltd. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ +// SPDX-License-Identifier: GPL-2.0 +// +// Regulators driver for Dialog Semiconductor DA903x +// +// Copyright (C) 2006-2008 Marvell International Ltd. +// Copyright (C) 2008 Compulab Ltd. #include #include diff --git a/drivers/regulator/da9052-regulator.c b/drivers/regulator/da9052-regulator.c index b90a7ac3f3de..e18d291c7f21 100644 --- a/drivers/regulator/da9052-regulator.c +++ b/drivers/regulator/da9052-regulator.c @@ -1,16 +1,10 @@ -/* -* da9052-regulator.c: Regulator driver for DA9052 -* -* Copyright(c) 2011 Dialog Semiconductor Ltd. -* -* Author: David Dajun Chen -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License as published by -* the Free Software Foundation; either version 2 of the License, or -* (at your option) any later version. -* -*/ +// SPDX-License-Identifier: GPL-2.0+ +// +// da9052-regulator.c: Regulator driver for DA9052 +// +// Copyright(c) 2011 Dialog Semiconductor Ltd. +// +// Author: David Dajun Chen #include #include diff --git a/drivers/regulator/da9055-regulator.c b/drivers/regulator/da9055-regulator.c index bcbc2fbd7fea..c025ccb1a30a 100644 --- a/drivers/regulator/da9055-regulator.c +++ b/drivers/regulator/da9055-regulator.c @@ -1,16 +1,10 @@ -/* -* Regulator driver for DA9055 PMIC -* -* Copyright(c) 2012 Dialog Semiconductor Ltd. -* -* Author: David Dajun Chen -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License as published by -* the Free Software Foundation; either version 2 of the License, or -* (at your option) any later version. -* -*/ +// SPDX-License-Identifier: GPL-2.0+ +// +// Regulator driver for DA9055 PMIC +// +// Copyright(c) 2012 Dialog Semiconductor Ltd. +// +// Author: David Dajun Chen #include #include diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-regulator.c index a7d929b7776a..a02e0488410f 100644 --- a/drivers/regulator/da9062-regulator.c +++ b/drivers/regulator/da9062-regulator.c @@ -1,17 +1,8 @@ -/* - * Regulator device driver for DA9061 and DA9062. - * Copyright (C) 2015-2017 Dialog Semiconductor - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ +// SPDX-License-Identifier: GPL-2.0+ +// +// Regulator device driver for DA9061 and DA9062. +// Copyright (C) 2015-2017 Dialog Semiconductor + #include #include #include diff --git a/drivers/regulator/da9210-regulator.c b/drivers/regulator/da9210-regulator.c index 528303771723..f9448ed50e05 100644 --- a/drivers/regulator/da9210-regulator.c +++ b/drivers/regulator/da9210-regulator.c @@ -1,22 +1,7 @@ -/* - * da9210-regulator.c - Regulator device driver for DA9210 - * Copyright (C) 2013 Dialog Semiconductor Ltd. - * - * This library is free software; you can redistribute it and/or - * modify it under the terms of the GNU Library General Public - * License as published by the Free Software Foundation; either - * version 2 of the License, or (at your option) any later version. - * - * This library is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * Library General Public License for more details. - * - * You should have
[PATCH 1/2] regulator: pv880x0: Switch to SPDX identifier
Convert Powerventure Semiconductor PV88060/PV88080/PV88090 regulator drivers to SPDX identifier. Signed-off-by: Axel Lin --- drivers/regulator/pv88060-regulator.c | 18 -- drivers/regulator/pv88060-regulator.h | 11 +-- drivers/regulator/pv88080-regulator.c | 18 -- drivers/regulator/pv88080-regulator.h | 11 +-- drivers/regulator/pv88090-regulator.c | 18 -- drivers/regulator/pv88090-regulator.h | 11 +-- 6 files changed, 15 insertions(+), 72 deletions(-) diff --git a/drivers/regulator/pv88060-regulator.c b/drivers/regulator/pv88060-regulator.c index 810816e9df5d..3d3415839ba2 100644 --- a/drivers/regulator/pv88060-regulator.c +++ b/drivers/regulator/pv88060-regulator.c @@ -1,17 +1,7 @@ -/* - * pv88060-regulator.c - Regulator device driver for PV88060 - * Copyright (C) 2015 Powerventure Semiconductor Ltd. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ +// SPDX-License-Identifier: GPL-2.0+ +// +// pv88060-regulator.c - Regulator device driver for PV88060 +// Copyright (C) 2015 Powerventure Semiconductor Ltd. #include #include diff --git a/drivers/regulator/pv88060-regulator.h b/drivers/regulator/pv88060-regulator.h index 02ca9203a172..d333dbf3be94 100644 --- a/drivers/regulator/pv88060-regulator.h +++ b/drivers/regulator/pv88060-regulator.h @@ -1,16 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ /* * pv88060-regulator.h - Regulator definitions for PV88060 * Copyright (C) 2015 Powerventure Semiconductor Ltd. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #ifndef __PV88060_REGISTERS_H__ diff --git a/drivers/regulator/pv88080-regulator.c b/drivers/regulator/pv88080-regulator.c index 6279216fb254..a444f68af1a8 100644 --- a/drivers/regulator/pv88080-regulator.c +++ b/drivers/regulator/pv88080-regulator.c @@ -1,17 +1,7 @@ -/* - * pv88080-regulator.c - Regulator device driver for PV88080 - * Copyright (C) 2016 Powerventure Semiconductor Ltd. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ +// SPDX-License-Identifier: GPL-2.0+ +// +// pv88080-regulator.c - Regulator device driver for PV88080 +// Copyright (C) 2016 Powerventure Semiconductor Ltd. #include #include diff --git a/drivers/regulator/pv88080-regulator.h b/drivers/regulator/pv88080-regulator.h index ae25ff360e3d..7d7f8f11a75a 100644 --- a/drivers/regulator/pv88080-regulator.h +++ b/drivers/regulator/pv88080-regulator.h @@ -1,16 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ /* * pv88080-regulator.h - Regulator definitions for PV88080 * Copyright (C) 2016 Powerventure Semiconductor Ltd. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #ifndef __PV88080_REGISTERS_H__ diff --git a/drivers/regulator/pv88090-regulator.c b/drivers/regulator/pv88090-regulator.c index 90f4f907fb3f..b1d0d97ae935 100644 --- a/drivers/regulator/pv88090-regulator.c +++ b/drivers/regulator/pv88090-regulator.c @@ -1,17 +1,7 @@ -/* - * pv88090-regulator.c - Regulator device driver for PV88090 - * Copyright (C) 2015 Powerventure Semiconductor Ltd. - * - * This program is free software; you can redistribute it and/or - *
linux-next: Fixes tag needs some work in the usb-gadget tree
Hi Felipe,
In commit
9f8dc24f7f5d ("usb: gadget: f_fs: don't free buffer prematurely")
Fixes tag
Fixes: 772a7a724f6 ("usb: gadget: f_fs: Allow scatter-gather buffers")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
pgpT4xFd0gjL7.pgp
Description: OpenPGP digital signature
[PATCH 3/3] ARM: dts: Add Avenger96 devicetree support based on STM32MP157A
Add devicetree support for Avenger96 board based on STM32MP157A MPU
from ST Micro. This board is one of the 96Boards Consumer Edition board
from Arrow Electronics and has the following features:
SoC: STM32MP157AAC
PMIC: STPMIC1A
RAM: 1024 Mbyte @ 533MHz
Storage: eMMC v4.51: 8 Gbyte
microSD Socket: UHS-1 v3.01
Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant
Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac
Bluetooth®v4.2 (BR/EDR/BLE)
USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG
Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
LED: 4x User LED, 1x WiFi LED, 1x BT LED
More information about this board can be found in 96Boards website:
https://www.96boards.org/product/avenger96/
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/stm32mp157a-avenger96.dts | 320
2 files changed, 321 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32mp157a-avenger96.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8a1d0b3f55dd..f1d2f0bfa7c2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -965,6 +965,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
stm32h743i-eval.dtb \
stm32h743i-disco.dtb \
stm32mp157a-dk1.dtb \
+ stm32mp157a-avenger96.dtb \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb
diff --git a/arch/arm/boot/dts/stm32mp157a-avenger96.dts
b/arch/arm/boot/dts/stm32mp157a-avenger96.dts
new file mode 100644
index ..a3b8af82ac70
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157a-avenger96.dts
@@ -0,0 +1,320 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
+ * Author: Manivannan Sadhasivam
+ */
+
+/dts-v1/;
+
+#include "stm32mp157c.dtsi"
+#include "stm32mp157-pinctrl.dtsi"
+#include
+#include
+
+/ {
+ model = "Arrow Electronics STM32MP157A Avenger96 board";
+ compatible = "arrow,stm32mp157a-avenger96", "st,stm32mp157";
+
+ aliases {
+ ethernet0 =
+ mmc0 =
+ serial0 =
+ serial1 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@c000 {
+ reg = <0xc000 0x4000>;
+ };
+
+ led {
+ compatible = "gpio-leds";
+ led1 {
+ label = "green:user1";
+ gpios = < 7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ led2 {
+ label = "green:user2";
+ gpios = < 3 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led3 {
+ label = "green:user3";
+ gpios = < 0 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc1";
+ default-state = "off";
+ };
+
+ led4 {
+ label = "green:user3";
+ gpios = < 1 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "none";
+ default-state = "off";
+ panic-indicator;
+ };
+
+ led5 {
+ label = "yellow:wifi";
+ gpios = < 3 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "phy0tx";
+ default-state = "off";
+ };
+
+ led6 {
+ label = "blue:bt";
+ gpios = < 6 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "bluetooth-power";
+ default-state = "off";
+ };
+ };
+};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_rgmii_pins_a>;
+ pinctrl-1 = <_rgmii_pins_sleep_a>;
+ pinctrl-names = "default", "sleep";
+ phy-mode = "rgmii";
+ max-speed = <1000>;
+ phy-handle = <>;
+
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy0: ethernet-phy@7 {
+ reg = <7>;
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_b>;
+ i2c-scl-rising-time-ns = <185>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+ /delete-property/dmas;
+ /delete-property/dma-names;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_b>;
+ i2c-scl-rising-time-ns = <185>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+ /delete-property/dmas;
+ /delete-property/dma-names;
+};
+
+ {
+
[PATCH 0/3] Add Avenger96 board support
Hello, This patchset adds Avenger96 board support. This board is one of the Consumer Edition boards of the 96Boards family from Arrow Electronics featuring STM32MP157A MPU and has the following features: SoC: STM32MP157AAC PMIC: STPMIC1A RAM: 1024 Mbyte @ 533MHz Storage: eMMC v4.51: 8 Gbyte microSD Socket: UHS-1 v3.01 Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac Bluetooth®v4.2 (BR/EDR/BLE) USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4 LED: 4x User LED, 1x WiFi LED, 1x BT LED More information about this board can be found in 96Boards website: https://www.96boards.org/product/avenger96/ Thanks, Mani Manivannan Sadhasivam (3): dt-bindings: arm: stm32: Document Avenger96 devicetree binding ARM: dts: stm32mp157: Add missing pinctrl definitions ARM: dts: Add Avenger96 devicetree support based on STM32MP157A .../devicetree/bindings/arm/stm32/stm32.txt | 6 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 62 arch/arm/boot/dts/stm32mp157a-avenger96.dts | 320 ++ 4 files changed, 389 insertions(+) create mode 100644 arch/arm/boot/dts/stm32mp157a-avenger96.dts -- 2.17.1
[PATCH 1/3] dt-bindings: arm: stm32: Document Avenger96 devicetree binding
Document devicetree binding for Avenger96 board. Signed-off-by: Manivannan Sadhasivam --- Documentation/devicetree/bindings/arm/stm32/stm32.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.txt b/Documentation/devicetree/bindings/arm/stm32/stm32.txt index 6808ed9ddfd5..eba363a4b514 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.txt +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.txt @@ -8,3 +8,9 @@ using one of the following compatible strings: st,stm32f746 st,stm32h743 st,stm32mp157 + +Boards: + +Root node property compatible must contain one of below depending on board: + + - Avenger96: "arrow,stm32mp157a-avenger96" -- 2.17.1
[PATCH 2/3] ARM: dts: stm32mp157: Add missing pinctrl definitions
Add missing pinctrl definitions for STM32MP157 MPU.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 62 +++
1 file changed, 62 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index 85c417d9983b..0b5bcf6a7c97 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -241,6 +241,23 @@
};
};
+ i2c1_pins_b: i2c1-2 {
+ pins {
+ pinmux = ,
/* I2C1_SCL */
+;
/* I2C1_SDA */
+ bias-disable;
+ drive-open-drain;
+ slew-rate = <0>;
+ };
+ };
+
+ i2c1_pins_sleep_b: i2c1-3 {
+ pins {
+ pinmux = , /* I2C1_SCL */
+; /* I2C1_SDA */
+ };
+ };
+
i2c2_pins_a: i2c2-0 {
pins {
pinmux = ,
/* I2C2_SCL */
@@ -258,6 +275,23 @@
};
};
+ i2c2_pins_b: i2c2-2 {
+ pins {
+ pinmux = ,
/* I2C2_SCL */
+;
/* I2C2_SDA */
+ bias-disable;
+ drive-open-drain;
+ slew-rate = <0>;
+ };
+ };
+
+ i2c2_pins_sleep_b: i2c2-3 {
+ pins {
+ pinmux = , /* I2C2_SCL */
+; /* I2C2_SDA */
+ };
+ };
+
i2c5_pins_a: i2c5-0 {
pins {
pinmux = ,
/* I2C5_SCL */
@@ -599,6 +633,34 @@
bias-disable;
};
};
+
+ uart4_pins_b: uart4-1 {
+ pins1 {
+ pinmux = ;
/* UART4_TX */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = ;
/* UART4_RX */
+ bias-disable;
+ };
+ };
+
+ uart7_pins_a: uart7-0 {
+ pins1 {
+ pinmux = ;
/* UART4_TX */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = ,
/* UART4_RX */
+,
/* UART4_CTS */
+;
/* UART4_RTS */
+ bias-disable;
+ };
+ };
};
pinctrl_z: pin-controller-z@54004000 {
--
2.17.1
Re: [PATCH v14 7/8] power: supply: Initial support for ROHM BD70528 PMIC charger block
Hello Sebastian,
On Thu, 2019-05-02 at 21:50 +0200, Sebastian Reichel wrote:
> Hi,
>
> On Thu, May 02, 2019 at 12:17:12PM +0300, Matti Vaittinen wrote:
> > ROHM BD70528 PMIC includes battery charger block. Support charger
> > staus queries and doing few basic settings like input current limit
> > and charging current.
> >
> > Signed-off-by: Matti Vaittinen
> > Acked-by: Sebastian Reichel
>
> Please only add Acked-by when you receive one, especially when you
> do not implement all requested changes :)
Sorry. This is my bad. I translated your: "Otherwise looks ok to me."
- to an ack. And I was pretty sure you didn't want to staticize the
local array. I should've known better. I should have waited for your Ok
to leaving the static out before adding an ack.
>
> > +static int bd70528_get_irqs(struct platform_device *pdev,
> > + struct bd70528_psy *bdpsy)
> > +{
> > + int irq, i, ret;
> > + unsigned int mask;
> > + const struct irq_name_pair bd70528_chg_irqs[] = {
> > + { .n = "bd70528-bat-ov-res", .h =
> > BD_IRQ_HND(BAT_OV_RES) },
> > + { .n = "bd70528-bat-ov-det", .h =
> > BD_IRQ_HND(BAT_OV_DET) },
> > + { .n = "bd70528-bat-dead", .h = BD_IRQ_HND(DBAT_DET) },
> > + { .n = "bd70528-bat-warmed", .h = BD_IRQ_HND(COLD_RES)
> > },
> > + { .n = "bd70528-bat-cold", .h = BD_IRQ_HND(COLD_DET) },
> > + { .n = "bd70528-bat-cooled", .h = BD_IRQ_HND(HOT_RES)
> > },
> > + { .n = "bd70528-bat-hot", .h = BD_IRQ_HND(HOT_DET) },
> > + { .n = "bd70528-chg-tshd", .h = BD_IRQ_HND(CHG_TSD) },
> > + { .n = "bd70528-bat-removed", .h = BD_IRQ_HND(BAT_RMV)
> > },
> > + { .n = "bd70528-bat-detected", .h = BD_IRQ_HND(BAT_DET)
> > },
> > + { .n = "bd70528-dcin2-ov-res", .h =
> > BD_IRQ_HND(DCIN2_OV_RES) },
> > + { .n = "bd70528-dcin2-ov-det", .h =
> > BD_IRQ_HND(DCIN2_OV_DET) },
> > + { .n = "bd70528-dcin2-removed", .h =
> > BD_IRQ_HND(DCIN2_RMV) },
> > + { .n = "bd70528-dcin2-detected", .h =
> > BD_IRQ_HND(DCIN2_DET) },
> > + { .n = "bd70528-dcin1-removed", .h =
> > BD_IRQ_HND(DCIN1_RMV) },
> > + { .n = "bd70528-dcin1-detected", .h =
> > BD_IRQ_HND(DCIN1_DET) },
> > + };
>
> Please also make it static. That will move the whole thing to
> read-only (because of const) data section. This improves the
> security and the required cpu time at the same time (no need
> to copy values to the stack).
Ok. I see your point and it sounds reasonable.
> But this can be changed later, so no need to block the whole
> patchset just because of this. If Lee wants to merge this for
> 5.2, that would be fine with me. But please add it directly in
> a new patch revision if the patch does not make it into 5.2.
It would be great to get this in, it has been respinned quite a few
times already... I hope Lee takes the series in when he's back from his
leave - but it is not a problem for me to change this with later patch
(or change this in the series if it still needs to be reworked).
Br,
Matti Vaittinen
Re: [PATCH v2 2/2] regmap: soundwire: fix Kconfig select/depend issue
On Fri, Apr 19, 2019 at 02:46:49PM -0500, Pierre-Louis Bossart wrote: > config REGMAP_SOUNDWIRE > tristate > - depends on SOUNDWIRE_BUS > + select SOUNDWIRE_BUS This now makes _SOUNDWIRE different to all the other bus types; if this is a good change then surely the same thing should be done for all the other bus types. It's also not clear to me that this actually does anything, do selects from symbols that are themselves selected actually do anything? signature.asc Description: PGP signature
Re: [PATCH v2] ASoC: Intel: avoid Oops if DMA setup fails
On Mon, Apr 29, 2019 at 12:25:17PM -0600, Ross Zwisler wrote: > Currently in sst_dsp_new() if we get an error return from sst_dma_new() > we just print an error message and then still complete the function > successfully. This means that we are trying to run without sst->dma Please don't bury patches in the replies to existing threads, it makes it harder to spot them. signature.asc Description: PGP signature
[PATCH v2 4/9] PCI/LINK: Prefix dmesg logs with PCIe service name
bw_notification.c currently does not have any dmesg logs. As the service continues to expand in functionality, prefix logs anyways. Signed-off-by: Frederick Lawler --- drivers/pci/pcie/bw_notification.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/pcie/bw_notification.c b/drivers/pci/pcie/bw_notification.c index d2eae3b7cc0f..a4bb90562cd5 100644 --- a/drivers/pci/pcie/bw_notification.c +++ b/drivers/pci/pcie/bw_notification.c @@ -14,6 +14,8 @@ * and warns when links become degraded in operation. */ +#define dev_fmt(fmt) "BWN: " fmt + #include "../pci.h" #include "portdrv.h" -- 2.17.1
[PATCH v2 8/9] PCI: hotplug: Remove unnecessary dbg/err/info/warn() printk() wrappers
Remove unnecessary deb/err/info/warn() printk() wrappers.
Signed-off-by: Frederick Lawler
---
drivers/pci/hotplug/pciehp.h | 9 -
drivers/pci/hotplug/pciehp_core.c | 4 ++--
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index e852aa478802..06ff9d31405e 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -31,15 +31,6 @@ extern bool pciehp_poll_mode;
extern int pciehp_poll_time;
extern bool pciehp_debug;
-#define dbg(format, arg...)\
- pr_debug(format, ## arg);
-#define err(format, arg...)\
- pr_err(format, ## arg)
-#define info(format, arg...) \
- pr_info(format, ## arg)
-#define warn(format, arg...) \
- pr_warn(format, ## arg)
-
#define ctrl_dbg(ctrl, format, arg...) \
pci_dbg(ctrl->pcie->port, format, ## arg)
#define ctrl_err(ctrl, format, arg...) \
diff --git a/drivers/pci/hotplug/pciehp_core.c
b/drivers/pci/hotplug/pciehp_core.c
index 7e06a0f9e644..67d024b7f476 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -331,9 +331,9 @@ int __init pcie_hp_init(void)
int retval = 0;
retval = pcie_port_service_register(_portdrv);
- dbg("pcie_port_service_register = %d\n", retval);
+ pr_debug("pcie_port_service_register = %d\n", retval);
if (retval)
- dbg("Failure to register service\n");
+ pr_debug("Failure to register service\n");
return retval;
}
--
2.17.1
[PATCH v2 3/9] PCI/PME: Prefix dmesg logs with PCIe service name
Prefix dmesg logs with PCIe service name. Signed-off-by: Frederick Lawler --- drivers/pci/pcie/pme.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c index 54d593d10396..d6698423a6d6 100644 --- a/drivers/pci/pcie/pme.c +++ b/drivers/pci/pcie/pme.c @@ -7,6 +7,8 @@ * Copyright (C) 2009 Rafael J. Wysocki , Novell Inc. */ +#define dev_fmt(fmt) "PME: " fmt + #include #include #include -- 2.17.1
[PATCH v2 7/9] PCI: hotplug: Prefer CONFIG_DYNAMIC_DEBUG/DEBUG for dmesg logs
dbg() and ctrl_dbg() requires pciehp_debug module parameter to be set
for debug log purposes. There are niche situations in pciehp_hpc.c where
pciehp_debug is used: dbg_ctrl(), and pci_bus_check_dev().
Enabling CONFIG_DYNAMIC_DEBUG/DEBUG is well known for logging debug
information. Therefore, prefer pr/pci_dbg() for debug information, and
reserve pciehp_debug for niche situations.
Signed-off-by: Frederick Lawler
---
drivers/pci/hotplug/pciehp.h | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index 78325c8d961e..e852aa478802 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -32,10 +32,7 @@ extern int pciehp_poll_time;
extern bool pciehp_debug;
#define dbg(format, arg...)\
-do { \
- if (pciehp_debug) \
- pr_info(format, ## arg);\
-} while (0)
+ pr_debug(format, ## arg);
#define err(format, arg...)\
pr_err(format, ## arg)
#define info(format, arg...) \
@@ -44,11 +41,7 @@ do {
\
pr_warn(format, ## arg)
#define ctrl_dbg(ctrl, format, arg...) \
- do {\
- if (pciehp_debug) \
- pci_info(ctrl->pcie->port, \
-format, ## arg); \
- } while (0)
+ pci_dbg(ctrl->pcie->port, format, ## arg)
#define ctrl_err(ctrl, format, arg...) \
pci_err(ctrl->pcie->port, format, ## arg)
#define ctrl_info(ctrl, format, arg...)
\
--
2.17.1
[PATCH v2 5/9] PCI/AER: Prefix dmesg logs with PCIe service name
Prefix dmesg logs with PCIe service name.
Signed-off-by: Frederick Lawler
---
drivers/pci/pcie/aer.c| 10 +++---
drivers/pci/pcie/aer_inject.c | 6 --
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 82eb45335b6f..e603084b8fc1 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -12,6 +12,9 @@
*Andrew Patterson
*/
+#define pr_fmt(fmt) "AER: " fmt
+#define dev_fmt pr_fmt
+
#include
#include
#include
@@ -1377,24 +1380,25 @@ static int aer_probe(struct pcie_device *dev)
int status;
struct aer_rpc *rpc;
struct device *device = >device;
+ struct pci_dev *port = dev->port;
rpc = devm_kzalloc(device, sizeof(struct aer_rpc), GFP_KERNEL);
if (!rpc) {
return -ENOMEM;
}
- rpc->rpd = dev->port;
+ rpc->rpd = port;
set_service_data(dev, rpc);
status = devm_request_threaded_irq(device, dev->irq, aer_irq, aer_isr,
IRQF_SHARED, "aerdrv", dev);
if (status) {
- dev_err(device, "request AER IRQ %d failed\n",
+ pci_err(port, "request AER IRQ %d failed\n",
dev->irq);
return status;
}
aer_enable_rootport(rpc);
- dev_info(device, "AER enabled with IRQ %d\n", dev->irq);
+ pci_info(port, "AER enabled with IRQ %d\n", dev->irq);
return 0;
}
diff --git a/drivers/pci/pcie/aer_inject.c b/drivers/pci/pcie/aer_inject.c
index 95d4759664b3..d4f6d49acd0c 100644
--- a/drivers/pci/pcie/aer_inject.c
+++ b/drivers/pci/pcie/aer_inject.c
@@ -12,6 +12,8 @@
* Huang Ying
*/
+#define dev_fmt(fmt) "AER: " fmt
+
#include
#include
#include
@@ -460,12 +462,12 @@ static int aer_inject(struct aer_error_inj *einj)
if (device) {
edev = to_pcie_device(device);
if (!get_service_data(edev)) {
- dev_warn(>device,
+ pci_warn(edev->port,
"aer_inject: AER service is not
initialized\n");
ret = -EPROTONOSUPPORT;
goto out_put;
}
- dev_info(>device,
+ pci_info(edev->port,
"aer_inject: Injecting errors %08x/%08x into device
%s\n",
einj->cor_status, einj->uncor_status, pci_name(dev));
local_irq_disable();
--
2.17.1
[PATCH v2 6/9] PCI: hotplug: Prefix dmesg logs with PCIe service name
Prefix dmesg logs with PCIe service name.
Signed-off-by: Frederick Lawler
---
drivers/pci/hotplug/pciehp.h | 18 +-
drivers/pci/hotplug/pciehp_core.c | 7 +--
drivers/pci/hotplug/pciehp_ctrl.c | 2 ++
drivers/pci/hotplug/pciehp_hpc.c | 4 +++-
drivers/pci/hotplug/pciehp_pci.c | 2 ++
5 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index 506e1d923a1f..78325c8d961e 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -34,27 +34,27 @@ extern bool pciehp_debug;
#define dbg(format, arg...)\
do { \
if (pciehp_debug) \
- printk(KERN_DEBUG "%s: " format, MY_NAME, ## arg); \
+ pr_info(format, ## arg);\
} while (0)
#define err(format, arg...)\
- printk(KERN_ERR "%s: " format, MY_NAME, ## arg)
+ pr_err(format, ## arg)
#define info(format, arg...) \
- printk(KERN_INFO "%s: " format, MY_NAME, ## arg)
+ pr_info(format, ## arg)
#define warn(format, arg...) \
- printk(KERN_WARNING "%s: " format, MY_NAME, ## arg)
+ pr_warn(format, ## arg)
#define ctrl_dbg(ctrl, format, arg...) \
do {\
if (pciehp_debug) \
- dev_printk(KERN_DEBUG, >pcie->device, \
- format, ## arg);\
+ pci_info(ctrl->pcie->port, \
+format, ## arg); \
} while (0)
#define ctrl_err(ctrl, format, arg...) \
- dev_err(>pcie->device, format, ## arg)
+ pci_err(ctrl->pcie->port, format, ## arg)
#define ctrl_info(ctrl, format, arg...)
\
- dev_info(>pcie->device, format, ## arg)
+ pci_info(ctrl->pcie->port, format, ## arg)
#define ctrl_warn(ctrl, format, arg...)
\
- dev_warn(>pcie->device, format, ## arg)
+ pci_warn(ctrl->pcie->port, format, ## arg)
#define SLOT_NAME_SIZE 10
diff --git a/drivers/pci/hotplug/pciehp_core.c
b/drivers/pci/hotplug/pciehp_core.c
index fc5366b50e95..7e06a0f9e644 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -17,6 +17,9 @@
* Dely Sy "
*/
+#define pr_fmt(fmt) "pciehp: " fmt
+#define dev_fmt pr_fmt
+
#include
#include
#include
@@ -182,14 +185,14 @@ static int pciehp_probe(struct pcie_device *dev)
if (!dev->port->subordinate) {
/* Can happen if we run out of bus numbers during probe */
- dev_err(>device,
+ pci_err(dev->port,
"Hotplug bridge without secondary bus, ignoring\n");
return -ENODEV;
}
ctrl = pcie_init(dev);
if (!ctrl) {
- dev_err(>device, "Controller initialization failed\n");
+ pci_err(dev->port, "Controller initialization failed\n");
return -ENODEV;
}
set_service_data(dev, ctrl);
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c
b/drivers/pci/hotplug/pciehp_ctrl.c
index 3f3df4c29f6e..bf81f977a751 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -13,6 +13,8 @@
*
*/
+#define dev_fmt(fmt) "pciehp: " fmt
+
#include
#include
#include
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 6a2365cd794e..1713b0b08a5e 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -12,6 +12,8 @@
* Send feedback to ,
*/
+#define dev_fmt(fmt) "pciehp: " fmt
+
#include
#include
#include
@@ -233,7 +235,7 @@ static bool pci_bus_check_dev(struct pci_bus *bus, int
devfn)
} while (delay > 0);
if (count > 1 && pciehp_debug)
- printk(KERN_DEBUG "pci %04x:%02x:%02x.%d id reading try %d
times with interval %d ms to get %08x\n",
+ pr_info("pci %04x:%02x:%02x.%d id reading try %d times with
interval %d ms to get %08x\n",
pci_domain_nr(bus), bus->number, PCI_SLOT(devfn),
PCI_FUNC(devfn), count, step, l);
diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index b9c1396db6fe..d17f3bf36f70 100644
--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -13,6 +13,8 @@
*
*/
+#define dev_fmt(fmt) "pciehp: " fmt
+
#include
#include
[PATCH v2 9/9] PCI: hotplug: Prefix ctrl_*() dmesg logs with pciehp slot name
Remove current uses of "Slot(%s)" and then prefix ctrl_*() dmesg
with pciehp slot name to include the slot name for all uses of ctrl_*()
wrappers.
Signed-off-by: Frederick Lawler
---
drivers/pci/hotplug/pciehp.h | 12 ---
drivers/pci/hotplug/pciehp_core.c | 9 +++--
drivers/pci/hotplug/pciehp_ctrl.c | 58 ---
drivers/pci/hotplug/pciehp_hpc.c | 5 ++-
4 files changed, 38 insertions(+), 46 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index 06ff9d31405e..e1cdc3565c62 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -32,13 +32,17 @@ extern int pciehp_poll_time;
extern bool pciehp_debug;
#define ctrl_dbg(ctrl, format, arg...) \
- pci_dbg(ctrl->pcie->port, format, ## arg)
+ pci_dbg(ctrl->pcie->port, "Slot(%s): " format, \
+ slot_name(ctrl), ## arg)
#define ctrl_err(ctrl, format, arg...) \
- pci_err(ctrl->pcie->port, format, ## arg)
+ pci_err(ctrl->pcie->port, "Slot(%s): " format, \
+ slot_name(ctrl), ## arg)
#define ctrl_info(ctrl, format, arg...)
\
- pci_info(ctrl->pcie->port, format, ## arg)
+ pci_info(ctrl->pcie->port, "Slot(%s): " format, \
+slot_name(ctrl), ## arg)
#define ctrl_warn(ctrl, format, arg...)
\
- pci_warn(ctrl->pcie->port, format, ## arg)
+ pci_warn(ctrl->pcie->port, "Slot(%s): " format, \
+slot_name(ctrl), ## arg)
#define SLOT_NAME_SIZE 10
diff --git a/drivers/pci/hotplug/pciehp_core.c
b/drivers/pci/hotplug/pciehp_core.c
index 67d024b7f476..ddaa45475572 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -85,7 +85,8 @@ static int init_slot(struct controller *ctrl)
retval = pci_hp_initialize(>hotplug_slot,
ctrl->pcie->port->subordinate, 0, name);
if (retval) {
- ctrl_err(ctrl, "pci_hp_initialize failed: error %d\n", retval);
+ pci_err(ctrl->pcie->port,
+ "pci_hp_initialize failed: error %d\n", retval);
kfree(ops);
}
return retval;
@@ -201,9 +202,11 @@ static int pciehp_probe(struct pcie_device *dev)
rc = init_slot(ctrl);
if (rc) {
if (rc == -EBUSY)
- ctrl_warn(ctrl, "Slot already registered by another
hotplug driver\n");
+ pci_warn(ctrl->pcie->port,
+"Slot already registered by another hotplug
driver\n");
else
- ctrl_err(ctrl, "Slot initialization failed (%d)\n", rc);
+ pci_err(ctrl->pcie->port,
+ "Slot initialization failed (%d)\n", rc);
goto err_out_release_ctlr;
}
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c
b/drivers/pci/hotplug/pciehp_ctrl.c
index bf81f977a751..046ec4d52159 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -76,7 +76,7 @@ static int board_added(struct controller *ctrl)
/* Check for a power fault */
if (ctrl->power_fault_detected || pciehp_query_power_fault(ctrl)) {
- ctrl_err(ctrl, "Slot(%s): Power fault\n", slot_name(ctrl));
+ ctrl_err(ctrl, "Power fault\n");
retval = -EIO;
goto err_exit;
}
@@ -160,12 +160,10 @@ void pciehp_handle_button_press(struct controller *ctrl)
case ON_STATE:
if (ctrl->state == ON_STATE) {
ctrl->state = BLINKINGOFF_STATE;
- ctrl_info(ctrl, "Slot(%s): Powering off due to button
press\n",
- slot_name(ctrl));
+ ctrl_info(ctrl, "Powering off due to button press\n");
} else {
ctrl->state = BLINKINGON_STATE;
- ctrl_info(ctrl, "Slot(%s) Powering on due to button
press\n",
- slot_name(ctrl));
+ ctrl_info(ctrl, "Powering on due to button press\n");
}
/* blink green LED and turn off amber */
pciehp_green_led_blink(ctrl);
@@ -179,7 +177,7 @@ void pciehp_handle_button_press(struct controller *ctrl)
* press the attention again before the 5 sec. limit
* expires to cancel hot-add or hot-remove
*/
- ctrl_info(ctrl, "Slot(%s): Button cancel\n", slot_name(ctrl));
+ ctrl_info(ctrl, "Button cancel\n");
cancel_delayed_work(>button_work);
if (ctrl->state == BLINKINGOFF_STATE) {
ctrl->state =
[PATCH v2 2/9] PCI/DPC: Prefix dmesg logs with PCIe service name
Prefix dmesg logs with PCIe service name.
Signed-off-by: Frederick Lawler
---
drivers/pci/pcie/dpc.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 7b77754a82de..934391c91c23 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -6,6 +6,8 @@
* Copyright (C) 2016 Intel Corp.
*/
+#define dev_fmt(fmt) "DPC: " fmt
+
#include
#include
#include
@@ -100,7 +102,6 @@ static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
{
unsigned long timeout = jiffies + HZ;
struct pci_dev *pdev = dpc->dev->port;
- struct device *dev = >dev->device;
u16 cap = dpc->cap_pos, status;
pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
@@ -110,7 +111,7 @@ static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
}
if (status & PCI_EXP_DPC_RP_BUSY) {
- dev_warn(dev, "DPC root port still busy\n");
+ pci_warn(pdev, "DPC root port still busy\n");
return -EBUSY;
}
return 0;
@@ -148,7 +149,6 @@ static pci_ers_result_t dpc_reset_link(struct pci_dev *pdev)
static void dpc_process_rp_pio_error(struct dpc_dev *dpc)
{
- struct device *dev = >dev->device;
struct pci_dev *pdev = dpc->dev->port;
u16 cap = dpc->cap_pos, dpc_status, first_error;
u32 status, mask, sev, syserr, exc, dw0, dw1, dw2, dw3, log, prefix;
@@ -156,13 +156,13 @@ static void dpc_process_rp_pio_error(struct dpc_dev *dpc)
pci_read_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_STATUS, );
pci_read_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_MASK, );
- dev_err(dev, "rp_pio_status: %#010x, rp_pio_mask: %#010x\n",
+ pci_err(pdev, "rp_pio_status: %#010x, rp_pio_mask: %#010x\n",
status, mask);
pci_read_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_SEVERITY, );
pci_read_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_SYSERROR, );
pci_read_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_EXCEPTION, );
- dev_err(dev, "RP PIO severity=%#010x, syserror=%#010x,
exception=%#010x\n",
+ pci_err(pdev, "RP PIO severity=%#010x, syserror=%#010x,
exception=%#010x\n",
sev, syserr, exc);
/* Get First Error Pointer */
@@ -171,7 +171,7 @@ static void dpc_process_rp_pio_error(struct dpc_dev *dpc)
for (i = 0; i < ARRAY_SIZE(rp_pio_error_string); i++) {
if ((status & ~mask) & (1 << i))
- dev_err(dev, "[%2d] %s%s\n", i, rp_pio_error_string[i],
+ pci_err(pdev, "[%2d] %s%s\n", i, rp_pio_error_string[i],
first_error == i ? " (First)" : "");
}
@@ -185,18 +185,18 @@ static void dpc_process_rp_pio_error(struct dpc_dev *dpc)
);
pci_read_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_HEADER_LOG + 12,
);
- dev_err(dev, "TLP Header: %#010x %#010x %#010x %#010x\n",
+ pci_err(pdev, "TLP Header: %#010x %#010x %#010x %#010x\n",
dw0, dw1, dw2, dw3);
if (dpc->rp_log_size < 5)
goto clear_status;
pci_read_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_IMPSPEC_LOG, );
- dev_err(dev, "RP PIO ImpSpec Log %#010x\n", log);
+ pci_err(pdev, "RP PIO ImpSpec Log %#010x\n", log);
for (i = 0; i < dpc->rp_log_size - 5; i++) {
pci_read_config_dword(pdev,
cap + PCI_EXP_DPC_RP_PIO_TLPPREFIX_LOG, );
- dev_err(dev, "TLP Prefix Header: dw%d, %#010x\n", i, prefix);
+ pci_err(pdev, "TLP Prefix Header: dw%d, %#010x\n", i, prefix);
}
clear_status:
pci_write_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_STATUS, status);
@@ -229,18 +229,17 @@ static irqreturn_t dpc_handler(int irq, void *context)
struct aer_err_info info;
struct dpc_dev *dpc = context;
struct pci_dev *pdev = dpc->dev->port;
- struct device *dev = >dev->device;
u16 cap = dpc->cap_pos, status, source, reason, ext_reason;
pci_read_config_word(pdev, cap + PCI_EXP_DPC_STATUS, );
pci_read_config_word(pdev, cap + PCI_EXP_DPC_SOURCE_ID, );
- dev_info(dev, "DPC containment event, status:%#06x source:%#06x\n",
+ pci_info(pdev, "DPC containment event, status:%#06x source:%#06x\n",
status, source);
reason = (status & PCI_EXP_DPC_STATUS_TRIGGER_RSN) >> 1;
ext_reason = (status & PCI_EXP_DPC_STATUS_TRIGGER_RSN_EXT) >> 5;
- dev_warn(dev, "DPC %s detected\n",
+ pci_warn(pdev, "DPC %s detected\n",
(reason == 0) ? "unmasked uncorrectable error" :
(reason == 1) ? "ERR_NONFATAL" :
(reason == 2) ? "ERR_FATAL" :
@@ -307,7 +306,7 @@ static int
[PATCH v2 1/9] PCI/AER: Cleanup dmesg logs
Cleanup dmesg logs.
Signed-off-by: Frederick Lawler
---
drivers/pci/pcie/aer.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index f8fc2114ad39..82eb45335b6f 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -964,8 +964,8 @@ static bool find_source_device(struct pci_dev *parent,
pci_walk_bus(parent->subordinate, find_device_iter, e_info);
if (!e_info->error_dev_num) {
- pci_printk(KERN_DEBUG, parent, "can't find device of ID%04x\n",
- e_info->id);
+ pci_info(parent, "can't find device of ID%04x\n",
+e_info->id);
return false;
}
return true;
@@ -1380,7 +1380,6 @@ static int aer_probe(struct pcie_device *dev)
rpc = devm_kzalloc(device, sizeof(struct aer_rpc), GFP_KERNEL);
if (!rpc) {
- dev_printk(KERN_DEBUG, device, "alloc AER rpc failed\n");
return -ENOMEM;
}
rpc->rpd = dev->port;
@@ -1389,8 +1388,8 @@ static int aer_probe(struct pcie_device *dev)
status = devm_request_threaded_irq(device, dev->irq, aer_irq, aer_isr,
IRQF_SHARED, "aerdrv", dev);
if (status) {
- dev_printk(KERN_DEBUG, device, "request AER IRQ %d failed\n",
- dev->irq);
+ dev_err(device, "request AER IRQ %d failed\n",
+ dev->irq);
return status;
}
@@ -1419,7 +1418,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
*dev)
pci_write_config_dword(dev, pos + PCI_ERR_ROOT_COMMAND, reg32);
rc = pci_bus_error_reset(dev);
- pci_printk(KERN_DEBUG, dev, "Root Port link has been reset\n");
+ pci_info(dev, "Root Port link has been reset\n");
/* Clear Root Error Status */
pci_read_config_dword(dev, pos + PCI_ERR_ROOT_STATUS, );
--
2.17.1
[PATCH v2 0/9] PCI: Use PCIe service name in dmesg logs
In referrence to [1], PCIe services did not have uniform logging via pci_*() printk wrappers. Add dev_fmt() to each service, clean up dmesg logs, use pci_dbg() for hotplug debug messages, and lastly, uniformally add Slot(%s) prefixes to hotplug ctrl_*() wrappers. 1. https://lore.kernel.org/linux-pci/20190308180149.gd214...@google.com/ Changes from v1: - Split dev_fmt() additions into own patches per service - Kept ctrl_*() wrappers and applied "Slot(%s)" prefix to messages - Attempted to leave no log gaps between patches Frederick Lawler (9): PCI/AER: Cleanup dmesg logs PCI/DPC: Prefix dmesg logs with PCIe service name PCI/PME: Prefix dmesg logs with PCIe service name PCI/LINK: Prefix dmesg logs with PCIe service name PCI/AER: Prefix dmesg logs with PCIe service name PCI: hotplug: Prefix dmesg logs with PCIe service name PCI: hotplug: Prefer CONFIG_DYNAMIC_DEBUG/DEBUG for dmesg logs PCI: hotplug: Remove unnecessary dbg/err/info/warn() printk() wrappers PCI: hotplug: Prefix ctrl_*() dmesg logs with pciehp slot name drivers/pci/hotplug/pciehp.h | 28 -- drivers/pci/hotplug/pciehp_core.c | 20 ++ drivers/pci/hotplug/pciehp_ctrl.c | 60 -- drivers/pci/hotplug/pciehp_hpc.c | 9 +++-- drivers/pci/hotplug/pciehp_pci.c | 2 + drivers/pci/pcie/aer.c | 19 ++ drivers/pci/pcie/aer_inject.c | 6 ++- drivers/pci/pcie/bw_notification.c | 2 + drivers/pci/pcie/dpc.c | 37 +- drivers/pci/pcie/pme.c | 2 + 10 files changed, 89 insertions(+), 96 deletions(-) -- 2.17.1
[PATCH] signal: Adjust error codes according to restore_user_sigmask()
For all the syscalls that receive a sigmask from the userland,
the user sigmask is to be in effect through the syscall execution.
At the end of syscall, sigmask of the current process is restored
to what it was before the switch over to user sigmask.
But, for this to be true in practice, the sigmask should be restored
only at the the point we change the saved_sigmask. Anything before
that loses signals. And, anything after is just pointless as the
signal is already lost by restoring the sigmask.
The issue was detected because of a regression caused by 854a6ed56839a.
The patch moved the signal_pending() check closer to restoring of the
user sigmask. But, it failed to update the error code accordingly.
Detailed issue discussion permalink:
https://lore.kernel.org/linux-fsdevel/20190427093319.sgicqik2oqkez3wk@dcvr/
Note that the patch returns interrupted errors (EINTR, ERESTARTNOHAND,
etc) only when there is no other error. If there is a signal and an error
like EINVAL, the syscalls return -EINVAL rather than the interrupted
error codes.
Reported-by: Eric Wong
Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
restore_user_sigmask()")
Signed-off-by: Deepa Dinamani
---
Sorry, I was trying a new setup at work. I should have tested it.
My bad, I've checked this one.
I've removed the questionable reported-by, since we're not sure if
it is actually the same issue.
fs/aio.c | 24
fs/eventpoll.c | 14 ++
fs/io_uring.c | 9 ++---
fs/select.c| 37 +
include/linux/signal.h | 2 +-
kernel/signal.c| 8 +---
6 files changed, 55 insertions(+), 39 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 38b741aef0bf..7de2f7573d55 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -2133,7 +2133,7 @@ SYSCALL_DEFINE6(io_pgetevents,
struct __aio_sigset ksig = { NULL, };
sigset_tksigmask, sigsaved;
struct timespec64 ts;
- int ret;
+ int ret, signal_detected;
if (timeout && unlikely(get_timespec64(, timeout)))
return -EFAULT;
@@ -2146,8 +2146,8 @@ SYSCALL_DEFINE6(io_pgetevents,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
- restore_user_sigmask(ksig.sigmask, );
- if (signal_pending(current) && !ret)
+ signal_detected = restore_user_sigmask(ksig.sigmask, );
+ if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
@@ -2166,7 +2166,7 @@ SYSCALL_DEFINE6(io_pgetevents_time32,
struct __aio_sigset ksig = { NULL, };
sigset_tksigmask, sigsaved;
struct timespec64 ts;
- int ret;
+ int ret, signal_detected;
if (timeout && unlikely(get_old_timespec32(, timeout)))
return -EFAULT;
@@ -2180,8 +2180,8 @@ SYSCALL_DEFINE6(io_pgetevents_time32,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
- restore_user_sigmask(ksig.sigmask, );
- if (signal_pending(current) && !ret)
+ signal_detected = restore_user_sigmask(ksig.sigmask, );
+ if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
@@ -2231,7 +2231,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents,
struct __compat_aio_sigset ksig = { NULL, };
sigset_t ksigmask, sigsaved;
struct timespec64 t;
- int ret;
+ int ret, signal_detected;
if (timeout && get_old_timespec32(, timeout))
return -EFAULT;
@@ -2244,8 +2244,8 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
- restore_user_sigmask(ksig.sigmask, );
- if (signal_pending(current) && !ret)
+ signal_detected = restore_user_sigmask(ksig.sigmask, );
+ if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
@@ -2264,7 +2264,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents_time64,
struct __compat_aio_sigset ksig = { NULL, };
sigset_t ksigmask, sigsaved;
struct timespec64 t;
- int ret;
+ int ret, signal_detected;
if (timeout && get_timespec64(, timeout))
return -EFAULT;
@@ -2277,8 +2277,8 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents_time64,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
- restore_user_sigmask(ksig.sigmask, );
- if (signal_pending(current) && !ret)
+ signal_detected = restore_user_sigmask(ksig.sigmask, );
+ if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 4a0e98d87fcc..fe5a0724b417 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -2317,7 +2317,7 @@
Re: [PATCH 2/4] devcoredump: allow to create several coredump files in one device
2019年5月2日(木) 21:47 Johannes Berg :
>
> On Thu, 2019-05-02 at 17:59 +0900, Akinobu Mita wrote:
> >
> > static void devcd_del(struct work_struct *wk)
> > {
> > struct devcd_entry *devcd;
> > + int i;
> >
> > devcd = container_of(wk, struct devcd_entry, del_wk.work);
> >
> > + for (i = 0; i < devcd->num_files; i++) {
> > + device_remove_bin_file(>devcd_dev,
> > +>files[i].bin_attr);
> > + }
>
> Not much value in the braces?
OK. I tend to use braces where a single statement but multiple lines.
> > +static struct devcd_entry *devcd_alloc(struct dev_coredumpm_bulk_data
> > *files,
> > +int num_files, gfp_t gfp)
> > +{
> > + struct devcd_entry *devcd;
> > + int i;
> > +
> > + devcd = kzalloc(sizeof(*devcd), gfp);
> > + if (!devcd)
> > + return NULL;
> > +
> > + devcd->files = kcalloc(num_files, sizeof(devcd->files[0]), gfp);
> > + if (!devcd->files) {
> > + kfree(devcd);
> > + return NULL;
> > + }
> > + devcd->num_files = num_files;
>
> IMHO it would be nicer to allocate all of this in one struct, i.e. have
>
> struct devcd_entry {
> ...
> struct devcd_file files[];
> }
>
> (and then use struct_size())
Sounds good.
> > @@ -309,7 +339,41 @@ void dev_coredumpm(struct device *dev, struct module
> > *owner,
> > put_module:
> > module_put(owner);
> > free:
> > - free(data);
> > + for (i = 0; i < num_files; i++)
> > + files[i].free(files[i].data);
> > +}
>
> and then you don't need to do all this kind of thing to free
>
> Otherwise looks fine. I'd worry a bit that existing userspace will only
> capture the 'data' file, rather than a tarball of all files, but I guess
> that's something you'd have to work out then when actually desiring to
> use multiple files.
Your worrying is correct. I'm going to create a empty 'data' file for nvme
coredump. Assuming that devcd* always contains the 'data' file at least,
we can simply write to 'data' when the device coredump is no longer needed,
and prepare for the newer coredump.
linux-next: manual merge of the modules tree with the vfs tree
Hi all,
Today's linux-next merge of the modules tree got a conflict in:
include/linux/module.h
between commit:
007ec26cdc9f ("vfs: Implement logging through fs_context")
from the vfs tree and commit:
dadec066d8fa ("module: add stubs for within_module functions")
from the modules tree.
I fixed it up (both these commits added the stub for
within_module_core, so I just used the latter) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpw6FV5D49z_.pgp
Description: OpenPGP digital signature
Re: [PATCH 0/4] nvme-pci: support device coredump
2019年5月2日(木) 22:03 Keith Busch : > > On Thu, May 02, 2019 at 05:59:17PM +0900, Akinobu Mita wrote: > > This enables to capture snapshot of controller information via device > > coredump machanism, and it helps diagnose and debug issues. > > > > The nvme device coredump is triggered before resetting the controller > > caused by I/O timeout, and creates the following coredump files. > > > > - regs: NVMe controller registers, including each I/O queue doorbell > > registers, in nvme-show-regs style text format. > > You're supposed to treat queue doorbells as write-only. Spec says: > > The host should not read the doorbell registers. If a doorbell register > is read, the value returned is vendor specific. OK. I'll exclude the doorbell registers from register dump. It will work out without the information if we have snapshot of the queues.
Re: Strange issues with epoll since 5.0
On Thu, 02 May 2019, Deepa Dinamani wrote: Reported-by: Omar Kilani Do we actually know if this was the issue Omar was hitting? Thanks, Davidlohr
-Wuninitialized warning in drivers/misc/sgi-xp/xpc_partition.c
Hi all, When building with -Wuninitialized, Clang warns: drivers/misc/sgi-xp/xpc_partition.c:73:14: warning: variable 'buf' is uninitialized when used within its own initialization [-Wuninitialized] void *buf = buf; ~~~ ^~~ 1 warning generated. I am not really sure how to properly initialize buf in this instance. I would assume it would involve xpc_kmalloc_cacheline_aligned like further down in the function but maybe not, this function isn't entirely clear. Could we get your input, this is one of the last warnings I see in a few allyesconfig builds. Thanks, Nathan
Re: [PATCH v3 1/3] PCI: qcom: Use clk_bulk API for 2.4.0 controllers
On 02-05-19, 08:00, Bjorn Andersson wrote:
> On Thu 02 May 04:53 PDT 2019, Vinod Koul wrote:
> > On 01-05-19, 17:19, Bjorn Andersson wrote:
> [..]
> > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> > > b/drivers/pci/controller/dwc/pcie-qcom.c
> > > index 0ed235d560e3..d740cbe0e56d 100644
> > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > > @@ -112,10 +112,10 @@ struct qcom_pcie_resources_2_3_2 {
> > > struct regulator_bulk_data supplies[QCOM_PCIE_2_3_2_MAX_SUPPLY];
> > > };
> > >
> > > +#define QCOM_PCIE_2_4_0_MAX_CLOCKS 3
> >
> > empty line after the define please
> >
>
> This follows the style of QCOM_PCIE_2_3_2_MAX_SUPPLY one block up, so
> I think this is the way we want it.
Okay sounds fine to me
>
> > > struct qcom_pcie_resources_2_4_0 {
> [..]
> >
> >
> > rest lgtm:
> >
> > Reviewed-by: Vinod Koul
> >
>
> Thanks!
>
> Regards,
> Bjorn
--
~Vinod
RE: [PATCH V2] clk: imx: pllv4: add fractional-N pll support
> From: Stephen Boyd [mailto:sb...@kernel.org] > Sent: Thursday, May 2, 2019 5:01 AM > > The Content-transfer-encoding header is still base64. I guess it can't be > fixed. > How can we know it's base64? As I saw from the 'Headers' in patchwork, it's: "Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit" https://patchwork.kernel.org/patch/10922657/ We'd like to fix it this. Regards Dong Aisheng > Quoting Anson Huang (2019-04-29 17:57:22) > > The pllv4 supports fractional-N function, the formula is: > > > > PLL output freq = input * (mult + num/denom), > > > > This patch adds fractional-N function support, including clock round > > rate, calculate rate and set rate, with this patch, the clock rate of > > APLL in clock tree is more accurate than before: > >
Re: Strange issues with epoll since 5.0
Deepa Dinamani wrote: > Eric, > Can you please help test this? Nope, that was _really_ badly whitespace-damaged. (C'mon, it's not like you're new to this)
Re: [PATCH] iio: dps310: Add pressure sensing capability
Hi Eddie, On Wed, 1 May 2019 at 14:43, Eddie James wrote: > > The DPS310 supports measurement of pressure, so support that in the > driver. Use background measurement like the temperature sensing and > default to lowest precision and lowest measurement rate. Upstream didn't accept my patch as they wanted it to support pressure in addition to temperature first. I didn't ever get around to doing that. I suggest you send my original patch and device tree binding along with this one as a series. Cheers, Joel
[PATCH] fix use-after-free in perf_sched__lat
After thread is added to machine->threads[i].dead in
__machine__remove_thread, the machine->threads[i].dead is freed
when calling free(session) in perf_session__delete(). So it get a
Segmentation fault when accessing it in thread__put().
In this patch, we delay the perf_session__delete until all threads
have been deleted.
This can be reproduced by following steps:
ulimit -c unlimited
export MALLOC_MMAP_THRESHOLD_=0
perf sched record sleep 10
perf sched latency --sort max
Segmentation fault (core dumped)
Signed-off-by: Zhipeng Xie
Signed-off-by: Wei Li
---
tools/perf/builtin-sched.c | 44 --
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index cbf39dab19c1..17849ae2eb1e 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -3130,11 +3130,48 @@ static void perf_sched__merge_lat(struct perf_sched
*sched)
static int perf_sched__lat(struct perf_sched *sched)
{
struct rb_node *next;
+ const struct perf_evsel_str_handler handlers[] = {
+ { "sched:sched_switch", process_sched_switch_event, },
+ { "sched:sched_stat_runtime", process_sched_runtime_event, },
+ { "sched:sched_wakeup", process_sched_wakeup_event, },
+ { "sched:sched_wakeup_new", process_sched_wakeup_event, },
+ { "sched:sched_migrate_task", process_sched_migrate_task_event,
},
+ };
+ struct perf_session *session;
+ struct perf_data data = {
+ .file = {
+ .path = input_name,
+ },
+ .mode = PERF_DATA_MODE_READ,
+ .force = sched->force,
+ };
+ int rc = -1;
setup_pager();
- if (perf_sched__read_events(sched))
+ session = perf_session__new(, false, >tool);
+ if (session == NULL) {
+ pr_debug("No Memory for session\n");
return -1;
+ }
+
+ symbol__init(>header.env);
+
+ if (perf_session__set_tracepoints_handlers(session, handlers))
+ goto out_delete;
+
+ if (perf_session__has_traces(session, "record -R")) {
+ int err = perf_session__process_events(session);
+
+ if (err) {
+ pr_err("Failed to process events, error %d", err);
+ goto out_delete;
+ }
+
+ sched->nr_events = session->evlist->stats.nr_events[0];
+ sched->nr_lost_events = session->evlist->stats.total_lost;
+ sched->nr_lost_chunks =
session->evlist->stats.nr_events[PERF_RECORD_LOST];
+ }
perf_sched__merge_lat(sched);
perf_sched__sort_lat(sched);
@@ -3163,7 +3200,10 @@ static int perf_sched__lat(struct perf_sched *sched)
print_bad_events(sched);
printf("\n");
- return 0;
+ rc = 0;
+out_delete:
+ perf_session__delete(session);
+ return rc;
}
static int setup_map_cpus(struct perf_sched *sched)
--
2.17.1
[PATCH] staging: kpc2000: kpc_spi: Fix build error for {read,write}q
drivers/staging/kpc2000/kpc_spi/spi_driver.c:158:11: error: implicit
declaration of function 'readq' [-Werror,-Wimplicit-function-declaration]
drivers/staging/kpc2000/kpc_spi/spi_driver.c:167:5: error: implicit
declaration of function 'writeq' [-Werror,-Wimplicit-function-declaration]
Same as commit 91b6cb7216cd ("staging: kpc2000: fix up build problems
with readq()").
Signed-off-by: Nathan Chancellor
---
drivers/staging/kpc2000/kpc_spi/spi_driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/kpc2000/kpc_spi/spi_driver.c
b/drivers/staging/kpc2000/kpc_spi/spi_driver.c
index 074a578153d0..3ace4e5c1284 100644
--- a/drivers/staging/kpc2000/kpc_spi/spi_driver.c
+++ b/drivers/staging/kpc2000/kpc_spi/spi_driver.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
2.21.0
[RFC][PATCH 1/2 v2] x86: Allow breakpoints to emulate call functions
[ This version of the patch passed all my tests! ]
From: Peter Zijlstra
In order to allow breakpoints to emulate call functions, they need to push
the return address onto the stack. But because the breakpoint exception
frame is added to the stack when the breakpoint is hit, there's no room to
add the address onto the stack and return to the address of the emulated
called funtion.
To handle this, copy the exception frame on entry of the breakpoint handler
and have leave a gap that can be used to add a return address to the stack
frame and return from the breakpoint to the emulated called function,
allowing for that called function to return back to the location after the
breakpoint was placed.
The helper functions were also added:
int3_emulate_push(): to push the address onto the gap in the stack
int3_emulate_jmp(): changes the location of the regs->ip to return there.
int3_emulate_call(): push the return address and change regs->ip
Cc: Andy Lutomirski
Cc: Nicolai Stange
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: the arch/x86 maintainers
Cc: Josh Poimboeuf
Cc: Jiri Kosina
Cc: Miroslav Benes
Cc: Petr Mladek
Cc: Joe Lawrence
Cc: Shuah Khan
Cc: Konrad Rzeszutek Wilk
Cc: Tim Chen
Cc: Sebastian Andrzej Siewior
Cc: Mimi Zohar
Cc: Juergen Gross
Cc: Nick Desaulniers
Cc: Nayna Jain
Cc: Masahiro Yamada
Cc: Joerg Roedel
Cc: "open list:KERNEL SELFTEST FRAMEWORK"
Cc: sta...@vger.kernel.org
Fixes: b700e7f03df5 ("livepatch: kernel: add support for live patching")
Signed-off-by: *** Need Peter Zijlstra's SoB here! ***
Signed-off-by: Steven Rostedt (VMware)
---
Changes since v1:
- Updated the 32bit code with Peter's latest changes
- Added int3 stack check in kernel_stack_pointer()
arch/x86/entry/entry_32.S| 117 +++
arch/x86/entry/entry_64.S| 14 +++-
arch/x86/include/asm/text-patching.h | 20 +
arch/x86/kernel/ptrace.c | 6 +-
4 files changed, 139 insertions(+), 18 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index d309f30cf7af..2885acd691ac 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -67,9 +67,20 @@
# define preempt_stop(clobbers)DISABLE_INTERRUPTS(clobbers);
TRACE_IRQS_OFF
#else
# define preempt_stop(clobbers)
-# define resume_kernel restore_all_kernel
#endif
+.macro RETINT_PREEMPT
+#ifdef CONFIG_PREEMPT
+ DISABLE_INTERRUPTS(CLBR_ANY)
+ cmpl$0, PER_CPU_VAR(__preempt_count)
+ jnz .Lend_\@
+ testl $X86_EFLAGS_IF, PT_EFLAGS(%esp) # interrupts off (exception
path) ?
+ jz .Lend_\@
+ callpreempt_schedule_irq
+.Lend_\@:
+#endif
+.endm
+
.macro TRACE_IRQS_IRET
#ifdef CONFIG_TRACE_IRQFLAGS
testl $X86_EFLAGS_IF, PT_EFLAGS(%esp) # interrupts off?
@@ -753,7 +764,7 @@ ret_from_intr:
andl$SEGMENT_RPL_MASK, %eax
#endif
cmpl$USER_RPL, %eax
- jb resume_kernel # not returning to v8086 or
userspace
+ jb restore_all_kernel # not returning to v8086 or
userspace
ENTRY(resume_userspace)
DISABLE_INTERRUPTS(CLBR_ANY)
@@ -763,19 +774,6 @@ ENTRY(resume_userspace)
jmp restore_all
END(ret_from_exception)
-#ifdef CONFIG_PREEMPT
-ENTRY(resume_kernel)
- DISABLE_INTERRUPTS(CLBR_ANY)
-.Lneed_resched:
- cmpl$0, PER_CPU_VAR(__preempt_count)
- jnz restore_all_kernel
- testl $X86_EFLAGS_IF, PT_EFLAGS(%esp) # interrupts off (exception
path) ?
- jz restore_all_kernel
- callpreempt_schedule_irq
- jmp .Lneed_resched
-END(resume_kernel)
-#endif
-
GLOBAL(__begin_SYSENTER_singlestep_region)
/*
* All code from here through __end_SYSENTER_singlestep_region is subject
@@ -1026,6 +1024,7 @@ restore_all:
INTERRUPT_RETURN
restore_all_kernel:
+ RETINT_PREEMPT
TRACE_IRQS_IRET
PARANOID_EXIT_TO_KERNEL_MODE
BUG_IF_WRONG_CR3
@@ -1476,6 +1475,94 @@ END(nmi)
ENTRY(int3)
ASM_CLAC
+
+#ifdef CONFIG_VM86
+ testl $X86_EFLAGS_VM, 8(%esp)
+ jnz .Lfrom_usermode_no_gap
+#endif
+ testl $SEGMENT_RPL_MASK, 4(%esp)
+ jnz .Lfrom_usermode_no_gap
+
+ /*
+* Here from kernel mode; so the (exception) stack looks like:
+*
+* 12(esp) -
+* 8(esp) - flags
+* 4(esp) - cs
+* 0(esp) - ip
+*
+* Lets build a 5 entry IRET frame after that, such that struct pt_regs
+* is complete and in particular regs->sp is correct. This gives us
+* the original 3 enties as gap:
+*
+* 32(esp) -
+* 28(esp) - orig_flags / gap
+* 24(esp) - orig_cs/ gap
+* 20(esp) - orig_ip/ gap
+* 16(esp) - ss
+* 12(esp) - sp
+* 8(esp) - flags
+* 4(esp) - cs
+* 0(esp) - ip
+*/
+ pushl
Re: [PATCH v2 2/2] prctl.2: Document the new PR_GET_TASK_SIZE option
On Thu, May 02, 2019 at 03:23:12PM -0700, Yury Norov wrote:
> чт, 2 мая 2019 г. в 13:52, Joel Savitz :
> >
> > Add a short explanation of the new PR_GET_TASK_SIZE option for the benefit
> > of future generations.
> >
> > Signed-off-by: Joel Savitz
> > ---
> > man2/prctl.2 | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/man2/prctl.2 b/man2/prctl.2
> > index 06d8e13c7..35a6a3919 100644
> > --- a/man2/prctl.2
> > +++ b/man2/prctl.2
> > @@ -49,6 +49,7 @@
> > .\" 2013-01-10 Kees Cook, document PR_SET_PTRACER
> > .\" 2012-02-04 Michael Kerrisk, document PR_{SET,GET}_CHILD_SUBREAPER
> > .\" 2014-11-10 Dave Hansen, document PR_MPX_{EN,DIS}ABLE_MANAGEMENT
> > +.\" 2019-05-02 Joel Savitz, document PR_GET_TASK_SIZE
> > .\"
> > .\"
> > .TH PRCTL 2 2019-03-06 "Linux" "Linux Programmer's Manual"
> > @@ -1375,6 +1376,14 @@ system call on Tru64).
> > for information on versions and architectures)
> > Return unaligned access control bits, in the location pointed to by
> > .IR "(unsigned int\ *) arg2" .
> > +.TP
> > +.B PR_GET_TASK_SIZE
> > +Copy the value of TASK_SIZE to the userspace address in
> > +.IR "(unsigned long\ *) arg2" .
>
> This is a bad idea to use pointers to size-undefined types in interface
> because
> that way you have to introduce compat versions of interface functions.
> I'd recommend you to use u64 or unsigned long long here.
>
unsigned long long seems to make little sense too as prctl(2) extra arguments
are of unsigned long type (good for passing the pointer address, in this case).
a pointer to an unsigned long var is OK for native builds, and for the
compat mode issue you correctly pointed out, the storage size needs to be
dealt with at the kernel side, by checking test_thread_flag(TIF_ADDR32),
before proceeding with copy_to_user().
> The comment not clear for reader not familiar with kernel internals.
> Can you rephrase
> TASK_SIZE like 'the (next after) highest possible userspace address',
> or similar?
>
> For the updated version could you please CC to yury.no...@gmail.com?
>
> > +Return
> > +.B EFAULT
> > +if this operation fails.
> > +
> > .SH RETURN VALUE
> > On success,
> > .BR PR_GET_DUMPABLE ,
> > --
> > 2.18.1
> >
Re: [PATCH v2 04/17] kunit: test: add kunit_stream a std::stream like logger
On 5/1/19 5:01 PM, Brendan Higgins wrote:
A lot of the expectation and assertion infrastructure prints out fairly
complicated test failure messages, so add a C++ style log library for
for logging test results.
Signed-off-by: Brendan Higgins
---
include/kunit/kunit-stream.h | 85
include/kunit/test.h | 2 +
kunit/Makefile | 3 +-
kunit/kunit-stream.c | 149 +++
kunit/test.c | 8 ++
5 files changed, 246 insertions(+), 1 deletion(-)
create mode 100644 include/kunit/kunit-stream.h
create mode 100644 kunit/kunit-stream.c
diff --git a/include/kunit/kunit-stream.h b/include/kunit/kunit-stream.h
new file mode 100644
index 0..d457a54fe0100
--- /dev/null
+++ b/include/kunit/kunit-stream.h
@@ -0,0 +1,85 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * C++ stream style string formatter and printer used in KUnit for outputting
+ * KUnit messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#ifndef _KUNIT_KUNIT_STREAM_H
+#define _KUNIT_KUNIT_STREAM_H
+
+#include
+#include
+
+struct kunit;
+
+/**
+ * struct kunit_stream - a std::stream style string builder.
+ *
+ * A std::stream style string builder. Allows messages to be built up and
+ * printed all at once.
+ */
+struct kunit_stream {
+ /* private: internal use only. */
+ struct kunit *test;
+ spinlock_t lock; /* Guards level. */
+ const char *level;
+ struct string_stream *internal_stream;
+};
+
+/**
+ * kunit_new_stream() - constructs a new kunit_stream.
+ * @test: The test context object.
+ *
+ * Constructs a new test managed kunit_stream.
+ */
+struct kunit_stream *kunit_new_stream(struct kunit *test);
+
+/**
+ * kunit_stream_set_level(): sets the level that string should be printed at.
+ * @this: the stream being operated on.
+ * @level: the print level the stream is set to output to.
+ *
+ * Sets the print level at which the stream outputs.
+ */
+void kunit_stream_set_level(struct kunit_stream *this, const char *level);
+
+/**
+ * kunit_stream_add(): adds the formatted input to the internal buffer.
+ * @this: the stream being operated on.
+ * @fmt: printf style format string to append to stream.
+ *
+ * Appends the formatted string, @fmt, to the internal buffer.
+ */
+void __printf(2, 3) kunit_stream_add(struct kunit_stream *this,
+const char *fmt, ...);
+
+/**
+ * kunit_stream_append(): appends the contents of @other to @this.
+ * @this: the stream to which @other is appended.
+ * @other: the stream whose contents are appended to @this.
+ *
+ * Appends the contents of @other to @this.
+ */
+void kunit_stream_append(struct kunit_stream *this, struct kunit_stream
*other);
+
+/**
+ * kunit_stream_commit(): prints out the internal buffer to the user.
+ * @this: the stream being operated on.
+ *
+ * Outputs the contents of the internal buffer as a kunit_printk formatted
+ * output.
+ */
+void kunit_stream_commit(struct kunit_stream *this);
+
+/**
+ * kunit_stream_clear(): clears the internal buffer.
+ * @this: the stream being operated on.
+ *
+ * Clears the contents of the internal buffer.
+ */
+void kunit_stream_clear(struct kunit_stream *this);
+
+#endif /* _KUNIT_KUNIT_STREAM_H */
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 819edd8db4e81..4668e8a635954 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -11,6 +11,7 @@
#include
#include
+#include
struct kunit_resource;
@@ -171,6 +172,7 @@ struct kunit {
void (*vprintk)(const struct kunit *test,
const char *level,
struct va_format *vaf);
+ void (*fail)(struct kunit *test, struct kunit_stream *stream);
};
int kunit_init_test(struct kunit *test, const char *name);
diff --git a/kunit/Makefile b/kunit/Makefile
index 275b565a0e81f..6ddc622ee6b1c 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_KUNIT) +=test.o \
- string-stream.o
+ string-stream.o \
+ kunit-stream.o
diff --git a/kunit/kunit-stream.c b/kunit/kunit-stream.c
new file mode 100644
index 0..93c14eec03844
--- /dev/null
+++ b/kunit/kunit-stream.c
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * C++ stream style string formatter and printer used in KUnit for outputting
+ * KUnit messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#include
+#include
+#include
+
+const char *kunit_stream_get_level(struct kunit_stream *this)
+{
+ unsigned long flags;
+ const char *level;
+
+ spin_lock_irqsave(>lock, flags);
+ level = this->level;
+ spin_unlock_irqrestore(>lock, flags);
+
+ return level;
+}
+
+void kunit_stream_set_level(struct kunit_stream *this,
Re: [RFC PATCH 3/5] kobject: Fix kernel-doc comment first line
On 5/2/19 6:40 PM, Tobin C. Harding wrote: > On Thu, May 02, 2019 at 10:39:22AM +0200, Johan Hovold wrote: >> On Thu, May 02, 2019 at 06:25:39PM +1000, Tobin C. Harding wrote: > Adding >> Jon to CC >>> >>> On Thu, May 02, 2019 at 09:38:23AM +0200, Johan Hovold wrote: On Thu, May 02, 2019 at 12:31:40PM +1000, Tobin C. Harding wrote: > kernel-doc comments have a prescribed format. This includes parenthesis > on the function name. To be _particularly_ correct we should also > capitalise the brief description and terminate it with a period. Why do think capitalisation and full stop is required for the function description? Sure, the example in the current doc happen to use that, but I'm not sure that's intended as a prescription. The old kernel-doc nano-HOWTO specifically did not use this: https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt >>> >>> Oh? I was basing this on Documentation/doc-guide/kernel-doc.rst >>> >>> Function documentation >>> -- >>> >>> The general format of a function and function-like macro kernel-doc >>> comment is:: >>> >>> /** >>>* function_name() - Brief description of function. >>>* @arg1: Describe the first argument. >>>* @arg2: Describe the second argument. >>>*One can provide multiple line descriptions >>>*for arguments. >>> >>> I figured that was the canonical way to do kernel-doc function >>> comments. I have however refrained from capitalising and adding the >>> period to argument strings to reduce code churn. I figured if I'm >>> touching the line to add parenthesis then I might as well make it >>> perfect (if such a thing exists). >> >> I think you may have read too much into that example. Many of the >> current function and parameter descriptions aren't even full sentences, >> so sentence case and full stop doesn't really make any sense. >> >> Looks like we discussed this last fall as well: > > Ha, this was funny. By 'we' at first I thought you meant 'we the kernel > community' but you actually meant we as in 'me and you'. Clearly you > failed to convince me last time :) > >> https://lkml.kernel.org/r/20180912093116.GC1089@localhost > > I am totally aware this is close to code churn and any discussion is > bikeshedding ... for me just because loads of places don't do this it > still looks nicer to my eyes > > /** > * sfn() - Super awesome function. > > than > > /** > */ sfn() - super awesome function > > I most likely will keep doing these changes if I am touching the > kernel-doc comments for other reasons and then drop the changes if the > subsystem maintainer thinks its code churn. > > I defiantly won't do theses changes in GNSS, GREYBUS, or USB SERIAL. > > Oh, and I'm totally going to CC you know every time I flick one of these > patches, prepare to get spammed :) I have seen this discussion before also. And sometimes it is not even a discussion -- it's more of an edict. To which I object/disagree. The current (or past) comment style is perfectly fine IMO. No caps needed. No ending '.' needed. -- ~Randy
[PATCH v2 RESEND] i2c-piix4: Add Hygon Dhyana SMBus support
The Hygon Dhyana CPU has the SMBus device with PCI device ID 0x790b,
which is the same as AMD CZ SMBus device. So add Hygon Dhyana support
to the i2c-piix4 driver by using the code path of AMD.
Signed-off-by: Pu Wen
Reviewed-by: Jean Delvare
---
v2 RESEND:
- Add 'Reviewed-by' tag from Jean Delvare.
v1->v2:
- Remove the revision number checking for Hygon SMBus device.
- Document the new supported chipset in drivers/i2c/busses/Kconfig
and Documentation/i2c/busses/i2c-piix4 as well as in the header
comment of i2c-piix4.c.
Documentation/i2c/busses/i2c-piix4 | 2 ++
drivers/i2c/busses/Kconfig | 1 +
drivers/i2c/busses/i2c-piix4.c | 15 +++
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/i2c/busses/i2c-piix4
b/Documentation/i2c/busses/i2c-piix4
index aa959fd..2703bc3 100644
--- a/Documentation/i2c/busses/i2c-piix4
+++ b/Documentation/i2c/busses/i2c-piix4
@@ -15,6 +15,8 @@ Supported adapters:
http://support.amd.com/us/Embedded_TechDocs/44413.pdf
* AMD Hudson-2, ML, CZ
Datasheet: Not publicly available
+ * Hygon CZ
+Datasheet: Not publicly available
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
Datasheet: Publicly available at the SMSC website http://www.smsc.com
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index f8979ab..50ec2e4 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -176,6 +176,7 @@ config I2C_PIIX4
AMD Hudson-2
AMD ML
AMD CZ
+ Hygon CZ
Serverworks OSB4
Serverworks CSB5
Serverworks CSB6
diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 90946a8..e9a0514 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -19,6 +19,7 @@
Serverworks OSB4, CSB5, CSB6, HT-1000, HT-1100
ATI IXP200, IXP300, IXP400, SB600, SB700/SP5100, SB800
AMD Hudson-2, ML, CZ
+ Hygon CZ
SMSC Victory66
Note: we assume there can only be one device, with one or more
@@ -289,7 +290,9 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
PIIX4_dev->revision >= 0x41) ||
(PIIX4_dev->vendor == PCI_VENDOR_ID_AMD &&
PIIX4_dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS &&
-PIIX4_dev->revision >= 0x49))
+PIIX4_dev->revision >= 0x49) ||
+ (PIIX4_dev->vendor == PCI_VENDOR_ID_HYGON &&
+PIIX4_dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS))
smb_en = 0x00;
else
smb_en = (aux) ? 0x28 : 0x2c;
@@ -361,7 +364,8 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
piix4_smba, i2ccfg >> 4);
/* Find which register is used for port selection */
- if (PIIX4_dev->vendor == PCI_VENDOR_ID_AMD) {
+ if (PIIX4_dev->vendor == PCI_VENDOR_ID_AMD ||
+ PIIX4_dev->vendor == PCI_VENDOR_ID_HYGON) {
switch (PIIX4_dev->device) {
case PCI_DEVICE_ID_AMD_KERNCZ_SMBUS:
piix4_port_sel_sb800 = SB800_PIIX4_PORT_IDX_KERNCZ;
@@ -794,6 +798,7 @@ static const struct pci_device_id piix4_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_KERNCZ_SMBUS) },
+ { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_AMD_KERNCZ_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_OSB4) },
{ PCI_DEVICE(PCI_VENDOR_ID_SERVERWORKS,
@@ -904,11 +909,13 @@ static int piix4_probe(struct pci_dev *dev, const struct
pci_device_id *id)
if ((dev->vendor == PCI_VENDOR_ID_ATI &&
dev->device == PCI_DEVICE_ID_ATI_SBX00_SMBUS &&
dev->revision >= 0x40) ||
- dev->vendor == PCI_VENDOR_ID_AMD) {
+ dev->vendor == PCI_VENDOR_ID_AMD ||
+ dev->vendor == PCI_VENDOR_ID_HYGON) {
bool notify_imc = false;
is_sb800 = true;
- if (dev->vendor == PCI_VENDOR_ID_AMD &&
+ if ((dev->vendor == PCI_VENDOR_ID_AMD ||
+dev->vendor == PCI_VENDOR_ID_HYGON) &&
dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS) {
u8 imc;
--
2.7.4
Re: [RFC PATCH 3/5] kobject: Fix kernel-doc comment first line
On Thu, May 02, 2019 at 10:39:22AM +0200, Johan Hovold wrote: > On Thu, May 02, 2019 at 06:25:39PM +1000, Tobin C. Harding wrote: > Adding > Jon to CC > > > > On Thu, May 02, 2019 at 09:38:23AM +0200, Johan Hovold wrote: > > > On Thu, May 02, 2019 at 12:31:40PM +1000, Tobin C. Harding wrote: > > > > kernel-doc comments have a prescribed format. This includes parenthesis > > > > on the function name. To be _particularly_ correct we should also > > > > capitalise the brief description and terminate it with a period. > > > > > > Why do think capitalisation and full stop is required for the function > > > description? > > > > > > Sure, the example in the current doc happen to use that, but I'm not > > > sure that's intended as a prescription. > > > > > > The old kernel-doc nano-HOWTO specifically did not use this: > > > > > > https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt > > > > > > > Oh? I was basing this on Documentation/doc-guide/kernel-doc.rst > > > > Function documentation > > -- > > > > The general format of a function and function-like macro kernel-doc > > comment is:: > > > > /** > >* function_name() - Brief description of function. > >* @arg1: Describe the first argument. > >* @arg2: Describe the second argument. > >*One can provide multiple line descriptions > >*for arguments. > > > > I figured that was the canonical way to do kernel-doc function > > comments. I have however refrained from capitalising and adding the > > period to argument strings to reduce code churn. I figured if I'm > > touching the line to add parenthesis then I might as well make it > > perfect (if such a thing exists). > > I think you may have read too much into that example. Many of the > current function and parameter descriptions aren't even full sentences, > so sentence case and full stop doesn't really make any sense. > > Looks like we discussed this last fall as well: Ha, this was funny. By 'we' at first I thought you meant 'we the kernel community' but you actually meant we as in 'me and you'. Clearly you failed to convince me last time :) > https://lkml.kernel.org/r/20180912093116.GC1089@localhost I am totally aware this is close to code churn and any discussion is bikeshedding ... for me just because loads of places don't do this it still looks nicer to my eyes /** * sfn() - Super awesome function. than /** */ sfn() - super awesome function I most likely will keep doing these changes if I am touching the kernel-doc comments for other reasons and then drop the changes if the subsystem maintainer thinks its code churn. I defiantly won't do theses changes in GNSS, GREYBUS, or USB SERIAL. Oh, and I'm totally going to CC you know every time I flick one of these patches, prepare to get spammed :) Cheers, Tobin.
Re: [PATCH] kobject: clean up the kobject add documentation a bit more
On Thu, May 02, 2019 at 12:22:24PM +0200, Greg Kroah-Hartman wrote:
> Commit 1fd7c3b438a2 ("kobject: Improve doc clarity kobject_init_and_add()")
> tried to provide more clarity, but the reference to kobject_del() was
> incorrect. Fix that up by removing that line, and hopefully be more explicit
> as to exactly what needs to happen here once you register a kobject with the
> kobject core.
>
> Cc: Tobin C. Harding
> Fixes: 1fd7c3b438a2 ("kobject: Improve doc clarity kobject_init_and_add()")
> Signed-off-by: Greg Kroah-Hartman
>
> diff --git a/lib/kobject.c b/lib/kobject.c
> index 3f4b7e95b0c2..f2ccdbac8ed9 100644
> --- a/lib/kobject.c
> +++ b/lib/kobject.c
> @@ -416,8 +416,12 @@ static __printf(3, 0) int kobject_add_varg(struct
> kobject *kobj,
> * to this function be directly freed with a call to kfree(),
> * that can leak memory.
> *
> - * If this call returns successfully and you later need to unwind
> - * kobject_add() for the error path you should call kobject_del().
> + * If this function returns success, kobject_put() must also be
> called
> + * in order to properly clean up the memory associated with the
> object.
> + *
> + * In short, once this function is called, kobject_put() MUST be
> called
> + * when the use of the object is finished in order to properly free
> + * everything.
> */
> int kobject_add(struct kobject *kobj, struct kobject *parent,
> const char *fmt, ...)
Ack! (Do I get to do those :)
I'm not convinced we have the docs for kobject clear enough for a
kobject noob to read but this patch defiantly fixes the error I
introduced.
thanks,
Tobin.
Re: [PATCH] MAINTAINERS: update git tree for sound entries
Hi, On Thu, May 02, 2019 at 11:27:00AM -0600, Ross Zwisler wrote: > Several sound related entries in MAINTAINERS refer to the old git tree > at "git://git.alsa-project.org/alsa-kernel.git". This is no longer used > for development, and Takashi Iwai's kernel.org tree is used instead. > > Signed-off-by: Ross Zwisler > --- > MAINTAINERS | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) This is a good catch. Reviewed-by: Takashi Sakamoto > diff --git a/MAINTAINERS b/MAINTAINERS > index e17ebf70b5480..d373d976a9317 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3351,7 +3351,7 @@ F: include/uapi/linux/bsg.h > BT87X AUDIO DRIVER > M: Clemens Ladisch > L: alsa-de...@alsa-project.org (moderated for non-subscribers) > -T: git git://git.alsa-project.org/alsa-kernel.git > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > S: Maintained > F: Documentation/sound/cards/bt87x.rst > F: sound/pci/bt87x.c > @@ -3404,7 +3404,7 @@ F: drivers/scsi/FlashPoint.* > C-MEDIA CMI8788 DRIVER > M: Clemens Ladisch > L: alsa-de...@alsa-project.org (moderated for non-subscribers) > -T: git git://git.alsa-project.org/alsa-kernel.git > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > S: Maintained > F: sound/pci/oxygen/ > > @@ -5696,7 +5696,7 @@ F: drivers/edac/qcom_edac.c > EDIROL UA-101/UA-1000 DRIVER > M: Clemens Ladisch > L: alsa-de...@alsa-project.org (moderated for non-subscribers) > -T: git git://git.alsa-project.org/alsa-kernel.git > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > S: Maintained > F: sound/usb/misc/ua101.c > > @@ -6036,7 +6036,7 @@ F: include/linux/f75375s.h > FIREWIRE AUDIO DRIVERS > M: Clemens Ladisch > L: alsa-de...@alsa-project.org (moderated for non-subscribers) > -T: git git://git.alsa-project.org/alsa-kernel.git > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > S: Maintained > F: sound/firewire/ > > @@ -11593,7 +11593,7 @@ F:Documentation/devicetree/bindings/opp/ > OPL4 DRIVER > M: Clemens Ladisch > L: alsa-de...@alsa-project.org (moderated for non-subscribers) > -T: git git://git.alsa-project.org/alsa-kernel.git > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > S: Maintained > F: sound/drivers/opl4/ > > @@ -14490,7 +14490,6 @@ M:Takashi Iwai > L: alsa-de...@alsa-project.org (moderated for non-subscribers) > W: http://www.alsa-project.org/ > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > -T: git git://git.alsa-project.org/alsa-kernel.git > Q: http://patchwork.kernel.org/project/alsa-devel/list/ > S: Maintained > F: Documentation/sound/ > @@ -16100,7 +16099,7 @@ F:drivers/usb/storage/ > USB MIDI DRIVER > M: Clemens Ladisch > L: alsa-de...@alsa-project.org (moderated for non-subscribers) > -T: git git://git.alsa-project.org/alsa-kernel.git > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > S: Maintained > F: sound/usb/midi.* > > -- > 2.21.0.593.g511ec345e18-goog Regards Takashi Sakamoto
next/master boot bisection: next-20190502 on beagle-xm
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
next/master boot bisection: next-20190502 on beagle-xm
Summary:
Start: e8b243ea3b19 Add linux-next specific files for 20190502
Details:https://kernelci.org/boot/id/5ccb3ece59b51417ae5584af
Plain log:
https://storage.kernelci.org//next/master/next-20190502/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-7/lab-baylibre/boot-omap3-beagle-xm.txt
HTML log:
https://storage.kernelci.org//next/master/next-20190502/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-7/lab-baylibre/boot-omap3-beagle-xm.html
Result: 6d25be5782e4 sched/core, workqueues: Distangle worker accounting
from rq lock
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: next
URL:git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Branch: master
Target: beagle-xm
CPU arch: arm
Lab:lab-baylibre
Compiler: gcc-7
Config: multi_v7_defconfig+CONFIG_SMP=n
Test suite: boot
Breaking commit found:
---
commit 6d25be5782e482eb93e3de0c94d0a517879377d0
Author: Thomas Gleixner
Date: Wed Mar 13 17:55:48 2019 +0100
sched/core, workqueues: Distangle worker accounting from rq lock
The worker accounting for CPU bound workers is plugged into the core
scheduler code and the wakeup code. This is not a hard requirement and
can be avoided by keeping track of the state in the workqueue code
itself.
Keep track of the sleeping state in the worker itself and call the
notifier before entering the core scheduler. There might be false
positives when the task is woken between that call and actually
scheduling, but that's not really different from scheduling and being
woken immediately after switching away. When nr_running is updated when
the task is retunrning from schedule() then it is later compared when it
is done from ttwu().
[ bigeasy: preempt_disable() around wq_worker_sleeping() by Daniel Bristot
de Oliveira ]
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Tejun Heo
Cc: Daniel Bristot de Oliveira
Cc: Lai Jiangshan
Cc: Linus Torvalds
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/ad2b29b5715f970bffc1a7026cabd6ff0b24076a.1532952814.git.bris...@redhat.com
Signed-off-by: Ingo Molnar
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4778c48a7fda..6184a0856aab 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1685,10 +1685,6 @@ static inline void ttwu_activate(struct rq *rq, struct
task_struct *p, int en_fl
{
activate_task(rq, p, en_flags);
p->on_rq = TASK_ON_RQ_QUEUED;
-
- /* If a worker is waking up, notify the workqueue: */
- if (p->flags & PF_WQ_WORKER)
- wq_worker_waking_up(p, cpu_of(rq));
}
/*
@@ -2106,56 +2102,6 @@ try_to_wake_up(struct task_struct *p, unsigned int
state, int wake_flags)
return success;
}
-/**
- * try_to_wake_up_local - try to wake up a local task with rq lock held
- * @p: the thread to be awakened
- * @rf: request-queue flags for pinning
- *
- * Put @p on the run-queue if it's not already there. The caller must
- * ensure that this_rq() is locked, @p is bound to this_rq() and not
- * the current task.
- */
-static void try_to_wake_up_local(struct task_struct *p, struct rq_flags *rf)
-{
- struct rq *rq = task_rq(p);
-
- if (WARN_ON_ONCE(rq != this_rq()) ||
- WARN_ON_ONCE(p == current))
- return;
-
- lockdep_assert_held(>lock);
-
- if (!raw_spin_trylock(>pi_lock)) {
- /*
-* This is OK, because current is on_cpu, which avoids it being
-* picked for load-balance and preemption/IRQs are still
-* disabled avoiding further scheduler activity on it and we've
-* not yet picked a replacement task.
-*/
- rq_unlock(rq, rf);
- raw_spin_lock(>pi_lock);
- rq_relock(rq, rf);
- }
-
- if (!(p->state & TASK_NORMAL))
- goto out;
-
- trace_sched_waking(p);
-
- if (!task_on_rq_queued(p)) {
- if (p->in_iowait) {
- delayacct_blkio_end(p);
- atomic_dec(>nr_iowait);
- }
- ttwu_activate(rq, p, ENQUEUE_WAKEUP | ENQUEUE_NOCLOCK);
-
linux-next: manual merge of the vfs tree with the kbuild tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
samples/Makefile
between commit:
a757ed09d672 ("samples: guard sub-directories with CONFIG options")
from the kbuild tree and commit:
f1b5618e013a ("vfs: Add a sample program for the new mount API")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc samples/Makefile
index 0f2d70d785f5,95d71ffd62d5..
--- a/samples/Makefile
+++ b/samples/Makefile
@@@ -1,21 -1,6 +1,21 @@@
+# SPDX-License-Identifier: GPL-2.0
# Makefile for Linux samples code
-obj-$(CONFIG_SAMPLES) += kobject/ kprobes/ trace_events/ livepatch/ \
- hw_breakpoint/ kfifo/ kdb/ hidraw/ rpmsg/ seccomp/ \
- configfs/ connector/ v4l/ trace_printk/ \
- vfio-mdev/ vfs/ qmi/ binderfs/
+obj-$(CONFIG_SAMPLE_ANDROID_BINDERFS) += binderfs/
+obj-$(CONFIG_SAMPLE_CONFIGFS) += configfs/
+obj-$(CONFIG_SAMPLE_CONNECTOR)+= connector/
+subdir-y += hidraw
+obj-$(CONFIG_SAMPLE_HW_BREAKPOINT)+= hw_breakpoint/
+obj-$(CONFIG_SAMPLE_KDB) += kdb/
+obj-$(CONFIG_SAMPLE_KFIFO)+= kfifo/
+obj-$(CONFIG_SAMPLE_KOBJECT) += kobject/
+obj-$(CONFIG_SAMPLE_KPROBES) += kprobes/
+obj-$(CONFIG_SAMPLE_LIVEPATCH)+= livepatch/
+obj-$(CONFIG_SAMPLE_QMI_CLIENT) += qmi/
+obj-$(CONFIG_SAMPLE_RPMSG_CLIENT) += rpmsg/
+subdir-$(CONFIG_SAMPLE_SECCOMP) += seccomp
- subdir-$(CONFIG_SAMPLE_STATX) += statx
++subdir-$(CONFIG_SAMPLE_VFS) += vfs
+obj-$(CONFIG_SAMPLE_TRACE_EVENTS) += trace_events/
+obj-$(CONFIG_SAMPLE_TRACE_PRINTK) += trace_printk/
+obj-$(CONFIG_VIDEO_PCI_SKELETON) += v4l/
+obj-y += vfio-mdev/
pgpsR8zWlJthp.pgp
Description: OpenPGP digital signature
Re: kobject_init_and_add() confusion
On Thu, May 02, 2019 at 10:34:12AM +0200, Petr Mladek wrote:
> On Wed 2019-05-01 09:38:03, Tobin C. Harding wrote:
> > Hi,
> >
> > Looks like I've created a bit of confusion trying to fix memleaks in
> > calls to kobject_init_and_add(). Its spread over various patches and
> > mailing lists so I'm starting a new thread and CC'ing anyone that
> > commented on one of those patches.
> >
> > If there is a better way to go about this discussion please do tell me.
> >
> > The problem
> > ---
> >
> > Calls to kobject_init_and_add() are leaking memory throughout the kernel
> > because of how the error paths are handled.
> >
> > The solution
> >
> >
> > Write the error path code correctly.
> >
> > Example
> > ---
> >
> > We have samples/kobject/kobject-example.c but it uses
> > kobject_create_and_add(). I thought of adding another example file here
> > but could not think of how to do it off the top of my head without being
> > super contrived. Can add this to the TODO list if it will help.
> >
> > Here is an attempted canonical usage of kobject_init_and_add() typical
> > of the code that currently is getting it wrong. This is the second time
> > I've written this and the first time it was wrong even after review (you
> > know who you are, you are definitely buying the next round of drinks :)
> >
> >
> > Assumes we have an object in memory already that has the kobject
> > embedded in it. Variable 'kobj' below would typically be >kobj
> >
> >
> > void fn(void)
> > {
> > int ret;
> >
> > ret = kobject_init_and_add(kobj, ktype, NULL, "foo");
> > if (ret) {
> > /*
> > * This means kobject_init() has succeeded
> > * but kobject_add() failed.
> > */
> > goto err_put;
> > }
>
> It is strange to make the structure visible in sysfs before
> we initialize it.
>
> > ret = some_init_fn();
> > if (ret) {
> > /*
> > * We need to wind back kobject_add() AND kobject_put().
> > * kobject_add() incremented the refcount in
> > * kobj->parent, that needs to be decremented THEN we
> > need
> > * the call to kobject_put() to decrement the
> > * refcount of kobj.
>*/
> > goto err_del;
> > }
> >
> > ret = some_other_init_fn();
> > if (ret)
> > goto other_err;
> >
> > kobject_uevent(kobj, KOBJ_ADD);
> > return 0;
> >
> > other_err:
> > other_clean_up_fn();
> > err_del:
> > kobject_del(kobj);
> > err_put:
> > kobject_put(kobj);
>
> IMHO, separate kobject_del() makes only sense when the sysfs
> interface must be destroyed before some other actions.
>
> I guess that we need two examples. I currently understand
> it the following way:
>
> 1. sysfs interface and the structure can be freed anytime:
>
> struct A
> {
> struct kobject kobj;
> ...
> };
>
> void fn(void)
> {
> struct A *a;
> int ret;
>
> a = kzalloc(sizeof(*a), GFP_KERNEL);
> if (!a)
> return;
>
> /*
>* Initialize structure before we make it accessible via
>* sysfs.
>*/
> ret = some_init_fn();
> if (ret) {
> goto init_err;
> }
>
> ret = kobject_init_and_add(>kobj, ktype, NULL, "foo");
> if (ret)
> goto kobj_err;
>
> return 0;
>
> kobj_err:
> /* kobject_init() always succeds and take reference. */
> kobject_put(kobj);
> return ret;
>
> init_err:
> /* kobject was not initialized, simple free is enough */
> kfree(a);
> return ret;
> }
>
>
> 2. Structure must be registered into the subsystem before
>it can be made visible via sysfs:
>
> struct A
> {
> struct kobject kobj;
> ...
> };
>
> void fn(void)
> {
> struct A *a;
> int ret;
>
> a = kzalloc(sizeof(*a), GFP_KERNEL);
> if (!a)
> return;
>
> ret = some_init_fn();
> if (ret) {
> goto init_err;
> }
>
> /*
>* Structure is in a reasonable state and can be freed
>* via the kobject release callback.
>*/
> kobject_init(>kobj);
>
> /*
>* Register the structure so that it can
linux-next: manual merge of the vfs tree with the orangefs tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
fs/orangefs/super.c
between commit:
77becb76042a ("orangefs: implement xattr cache")
from the orangefs tree and commit:
f276ae0dd6d0 ("orangefs: make use of ->free_inode()")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/orangefs/super.c
index 8fa30c13b7ed,3784f7e8b603..
--- a/fs/orangefs/super.c
+++ b/fs/orangefs/super.c
@@@ -125,20 -124,9 +125,19 @@@ static struct inode *orangefs_alloc_ino
return _inode->vfs_inode;
}
- static void orangefs_i_callback(struct rcu_head *head)
+ static void orangefs_free_inode(struct inode *inode)
{
- struct inode *inode = container_of(head, struct inode, i_rcu);
- kmem_cache_free(orangefs_inode_cache, ORANGEFS_I(inode));
+ struct orangefs_inode_s *orangefs_inode = ORANGEFS_I(inode);
+ struct orangefs_cached_xattr *cx;
+ struct hlist_node *tmp;
+ int i;
+
+ hash_for_each_safe(orangefs_inode->xattr_cache, i, tmp, cx, node) {
+ hlist_del(>node);
+ kfree(cx);
+ }
+
+ kmem_cache_free(orangefs_inode_cache, orangefs_inode);
}
static void orangefs_destroy_inode(struct inode *inode)
@@@ -148,17 -136,8 +147,15 @@@
gossip_debug(GOSSIP_SUPER_DEBUG,
"%s: deallocated %p destroying inode %pU\n",
__func__, orangefs_inode, get_khandle_from_ino(inode));
-
- call_rcu(>i_rcu, orangefs_i_callback);
}
+static int orangefs_write_inode(struct inode *inode,
+ struct writeback_control *wbc)
+{
+ gossip_debug(GOSSIP_SUPER_DEBUG, "orangefs_write_inode\n");
+ return orangefs_inode_setattr(inode);
+}
+
/*
* NOTE: information filled in here is typically reflected in the
* output of the system command 'df'
@@@ -316,8 -295,8 +313,9 @@@ void fsid_key_table_finalize(void
static const struct super_operations orangefs_s_ops = {
.alloc_inode = orangefs_alloc_inode,
+ .free_inode = orangefs_free_inode,
.destroy_inode = orangefs_destroy_inode,
+ .write_inode = orangefs_write_inode,
.drop_inode = generic_delete_inode,
.statfs = orangefs_statfs,
.remount_fs = orangefs_remount_fs,
pgpO2ohcbdVDO.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the vfs tree with the fscrypt tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
fs/ext4/super.c
fs/f2fs/super.c
between commit:
2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link")
from the fscrypt tree and commits:
94053139d482 ("ext4: make use of ->free_inode()")
d01718a050d0 ("f2fs: switch to ->free_inode()")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
Thanks, Al, for the heads up and example merge.
--
Cheers,
Stephen Rothwell
diff --cc fs/ext4/super.c
index 489cdeeab789,981f702848e7..
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@@ -,12 -1107,8 +,9 @@@ static int ext4_drop_inode(struct inod
return drop;
}
- static void ext4_i_callback(struct rcu_head *head)
+ static void ext4_free_in_core_inode(struct inode *inode)
{
- struct inode *inode = container_of(head, struct inode, i_rcu);
-
+ fscrypt_free_inode(inode);
-
kmem_cache_free(ext4_inode_cachep, EXT4_I(inode));
}
diff --cc fs/f2fs/super.c
index f7605b3ff1f9,9924eac76254..
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@@ -1000,12 -1000,8 +1000,9 @@@ static void f2fs_dirty_inode(struct ino
f2fs_inode_dirtied(inode, false);
}
- static void f2fs_i_callback(struct rcu_head *head)
+ static void f2fs_free_inode(struct inode *inode)
{
- struct inode *inode = container_of(head, struct inode, i_rcu);
-
+ fscrypt_free_inode(inode);
-
kmem_cache_free(f2fs_inode_cachep, F2FS_I(inode));
}
pgpc1Ly4duZ7F.pgp
Description: OpenPGP digital signature
INFO: task hung in mount_bdev (2)
Hello, syzbot found the following crash on: HEAD commit:9520b532 Merge tag 'for-linus' of git://git.armlinux.org.u.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1104bb90a0 kernel config: https://syzkaller.appspot.com/x/.config?x=a42d110b47dd6b36 dashboard link: https://syzkaller.appspot.com/bug?extid=97889fb583ef1f3d42c6 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10357834a0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10e1d160a0 Bisection is inconclusive: the bug happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1478aa98a0 console output: https://syzkaller.appspot.com/x/log.txt?x=1278aa98a0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+97889fb583ef1f3d4...@syzkaller.appspotmail.com INFO: task syz-executor013:7561 blocked for more than 143 seconds. Not tainted 5.1.0-rc6+ #90 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor013 D29336 7561 7543 0x0004 Call Trace: context_switch kernel/sched/core.c:2877 [inline] __schedule+0x813/0x1cc0 kernel/sched/core.c:3518 schedule+0x92/0x180 kernel/sched/core.c:3562 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3620 __mutex_lock_common kernel/locking/mutex.c:1002 [inline] __mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087 mount_bdev+0x93/0x3c0 fs/super.c:1313 udf_mount+0x35/0x40 fs/udf/super.c:131 legacy_get_tree+0xf2/0x200 fs/fs_context.c:584 vfs_get_tree+0x123/0x450 fs/super.c:1481 do_new_mount fs/namespace.c:2622 [inline] do_mount+0x1436/0x2c40 fs/namespace.c:2942 ksys_mount+0xdb/0x150 fs/namespace.c:3151 __do_sys_mount fs/namespace.c:3165 [inline] __se_sys_mount fs/namespace.c:3162 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3162 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x44a739 Code: 00 49 6e 76 61 6c 69 64 20 22 24 41 63 74 69 6f 6e 51 75 65 75 65 43 68 65 63 6b 70 6f 69 6e 74 49 6e 74 65 72 76 61 6c 22 2c <20> 65 72 72 6f 72 20 25 64 2e 20 49 67 6e 6f 72 65 64 2c 20 72 75 RSP: 002b:7f9541ef0db8 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: 006dbc28 RCX: 0044a739 RDX: 2240 RSI: 2200 RDI: 2080 RBP: 006dbc20 R08: R09: R10: R11: 0246 R12: 006dbc2c R13: 7ffc6cf3cddf R14: 7f9541ef19c0 R15: INFO: task syz-executor013:7563 blocked for more than 143 seconds. Not tainted 5.1.0-rc6+ #90 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor013 D29720 7563 7541 0x0004 Call Trace: context_switch kernel/sched/core.c:2877 [inline] __schedule+0x813/0x1cc0 kernel/sched/core.c:3518 schedule+0x92/0x180 kernel/sched/core.c:3562 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3620 __mutex_lock_common kernel/locking/mutex.c:1002 [inline] __mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087 mount_bdev+0x93/0x3c0 fs/super.c:1313 udf_mount+0x35/0x40 fs/udf/super.c:131 legacy_get_tree+0xf2/0x200 fs/fs_context.c:584 vfs_get_tree+0x123/0x450 fs/super.c:1481 do_new_mount fs/namespace.c:2622 [inline] do_mount+0x1436/0x2c40 fs/namespace.c:2942 ksys_mount+0xdb/0x150 fs/namespace.c:3151 __do_sys_mount fs/namespace.c:3165 [inline] __se_sys_mount fs/namespace.c:3162 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3162 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x44a739 Code: 00 49 6e 76 61 6c 69 64 20 22 24 41 63 74 69 6f 6e 51 75 65 75 65 43 68 65 63 6b 70 6f 69 6e 74 49 6e 74 65 72 76 61 6c 22 2c <20> 65 72 72 6f 72 20 25 64 2e 20 49 67 6e 6f 72 65 64 2c 20 72 75 RSP: 002b:7f9541ef0db8 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: 006dbc28 RCX: 0044a739 RDX: 2240 RSI: 2200 RDI: 2080 RBP: 006dbc20 R08: R09: R10: R11: 0246 R12: 006dbc2c R13: 7ffc6cf3cddf R14: 7f9541ef19c0 R15: INFO: task syz-executor013:7559 blocked for more than 143 seconds. Not tainted 5.1.0-rc6+ #90 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor013 D29096 7559 7544 0x0004 Call Trace: context_switch kernel/sched/core.c:2877 [inline] __schedule+0x813/0x1cc0 kernel/sched/core.c:3518 schedule+0x92/0x180 kernel/sched/core.c:3562 __rwsem_down_write_failed_common kernel/locking/rwsem-xadd.c:582 [inline] rwsem_down_write_failed+0x774/0xc30
Re: [PATCH] kexec_buffer measure
On 2019/05/03 1:28, Casey Schaufler wrote: > On 5/2/2019 8:48 AM, Mimi Zohar wrote: >> [Cc'ing Paul, John, Casey] >> >> On Mon, 2019-04-22 at 20:18 -0400, Mimi Zohar wrote: >>> [Cc'ing LSM mailing list] >>> >>> On Fri, 2019-04-19 at 17:30 -0700, prakhar srivastava wrote: >>> 2) Adding a LSM hook We are doing both the command line and kernel version measurement in IMA. Can you please elaborate on how this can be used outside of the scenario? That will help me come back with a better design and code. I am neutral about this. >>> As I said previously, initially you might want to only measure the >>> kexec boot command line, but will you ever want to verify or audit log >>> the boot command line hash? Perhaps LSMs would be interested in the >>> boot command line. Should this be an LSM hook? >> From an LSM perspective, is there any interest in the boot command line? > > I can imagine an LSM that cares about the command line, > but I don't have interest in it for any work I have in progress. > Since the kernel command line controls which LSMs to enable, I doubt that an LSM which cares about the command line can detect that the kernel command line was tampered when the kernel command line was tampered...
Re: [PATCH 1/2] pinctrl: mediatek: Add mtk_eint_pm_ops to common-v2
On Thu, May 2, 2019 at 9:48 PM Yingjoe Chen wrote:
>
> On Mon, 2019-04-29 at 11:25 +0800, Nicolas Boichat wrote:
> > pinctrl variants that include pinctrl-mtk-common-v2.h (and not
> > pinctrl-mtk-common.h) also need to use mtk_eint_pm_ops to setup
> > wake mask properly, so copy over the pm_ops to v2.
> >
> > It is not easy to merge the 2 copies (or move
> > mtk_eint_suspend/resume to mtk-eint.c), as we need to
> > dereference pctrl->eint, and struct mtk_pinctrl *pctl has a
> > different structure definition for v1 and v2.
> >
> > Signed-off-by: Nicolas Boichat
> > Reviewed-by: Chuanjia Liu
> > ---
> > .../pinctrl/mediatek/pinctrl-mtk-common-v2.c | 19 +++
> > .../pinctrl/mediatek/pinctrl-mtk-common-v2.h | 1 +
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > index 20e1c890e73b30c..7e19b5a4748eafe 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > @@ -723,3 +723,22 @@ int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
> >
> > return 0;
> > }
> > +
> > +static int mtk_eint_suspend(struct device *device)
> > +{
> > + struct mtk_pinctrl *pctl = dev_get_drvdata(device);
> > +
> > + return mtk_eint_do_suspend(pctl->eint);
> > +}
> > +
> > +static int mtk_eint_resume(struct device *device)
> > +{
> > + struct mtk_pinctrl *pctl = dev_get_drvdata(device);
> > +
> > + return mtk_eint_do_resume(pctl->eint);
> > +}
> > +
> > +const struct dev_pm_ops mtk_eint_pm_ops = {
> > + .suspend_noirq = mtk_eint_suspend,
> > + .resume_noirq = mtk_eint_resume,
> > +};
>
> This is identical to the one in pinctrl-mtk-common.c and will have name
> clash if both pinctrl-mtk-common.c and pinctrl-mtk-common-v2.c are
> built.
>
> It would be better if we try to merge both version into mtk-eint.c, this
> way we could also remove some global functions.
Argh, I didn't think about the name clash, you're right. I guess the
easy way is to rename this one mtk_eint_pm_ops_v2 ...
As highlighted in the commit message, it's tricky to merge the 2 sets
of functions, they look identical, but they actually work on struct
mtk_pinctrl that are defined differently (in
pinctrl-mtk-common[-v2].h), so the ->eint member is at different
addresses...
I don't really see a way around this... Unless we want to change
platform_set_drvdata(pdev, pctl); to pass another type of structure
that could be shared (but I think that'll make the code fairly
verbose, with another layer of indirection). Or just assign struct
mtk_eint to that, since that contains pctl so we could get back the
struct mtk_pinctrl from that, but that feels ugly as well...
>
> Joe.C
>
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support
03.05.2019 3:31, Chanwoo Choi пишет: > Hi Dmitry, > > On 19. 5. 2. 오전 8:37, Dmitry Osipenko wrote: >> Changelog: >> >> v4: Addressed all review comments that were made by Chanwoo Choi to v3: >> >> - changed the driver removal order to match the probe exactly >> - added clarifying comment for 1/8 ratio to the Tegra20 driver >> >> Chanwoo, please also note that the clk patch that should fix >> compilation problem that was reported the kbuild-test-robot is already >> applied and available in the recent linux-next. > > I knew that Stephen picked up your path about clock. Hi Chanwoo, Okay, good. Thank you very much for reviewing this series! I assume it's too late now for v5.2, but it should be good to go for v5.3.
Re: linux-next: Tree for May 2
On 03/05/2019 00:03, Stephen Rothwell wrote:
> Hi Daniel,
>
> On Thu, 2 May 2019 22:09:49 +0200 Daniel Lezcano
> wrote:
>>
>> Yes, I picked the patch and it was merged it via the tip tree [1] as
>> requested by Marc Zyngier [2] and notified [3].
>>
>> In any case, this patch should have go through my tree initially, so if
>> it is found somewhere else that's wrong.
>>
>> I did a respin of my branch and pushed it again in case there was
>> something wrong from it.
>
> The patch ("clocksource/drivers/arch_timer: Workaround for Allwinner
> A64 timer instability") was merged into v5.1-rc1 via the tip tree as
> you say, however the version of your clockevents tree in yesterday's
> linux-next was based on v5.0-rc1 and contained the patch again ...
>
> Today's should be better.
Oh, ok. As I updated the branch today before having this merge conflict
I thought the problem was coming from somewhere else. Thanks for the update.
--
Facebook |
Twitter |
Re: [PATCH v5 3/6] devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.
Hi
Also, this patch was applied to linux-pm.git for for v5.2-rc1.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge=adfe3b76608ffe547af5a74415f15499b798f32a
On 19. 5. 3. 오전 2:58, Gaël PORTAY wrote:
> From: Enric Balletbo i Serra
>
> Trusted Firmware-A (TF-A) for rk3399 implements a SiP call to get the
> on-die termination (ODT) and auto power down parameters from kernel,
> this patch adds the functionality to do this. Also, if DDR clock
> frequency is lower than the on-die termination (ODT) disable frequency
> this driver should disable the DDR ODT.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Chanwoo Choi
> Signed-off-by: Gaël PORTAY
> Acked-by: MyungJoo Ham
> ---
>
> Changes in v5: None
>
> Changes in v4:
> - [PATCH v3 3/5] Add Acked-by: MyungJoo Ham .
>
> Changes in v3:
> - [PATCH v2 3/5] Add Signed-off-by: Gaël PORTAY .
>Remove comments.
>Move pmu dt parsing after dt-parsing of timings to fix
> data->odt_dis_freq value.
>
> Changes in v2: None
>
> Changes in v1:
> - [RFC 3/10] Add an explanation for platform SIP calls.
> - [RFC 3/10] Change if statement for a switch.
> - [RFC 3/10] Rename ddr_flag to odt_enable to be more clear.
>
> drivers/devfreq/rk3399_dmc.c| 71 -
> include/soc/rockchip/rockchip_sip.h | 1 +
> 2 files changed, 71 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> index e795ad2b3f6b..daf19e121c99 100644
> --- a/drivers/devfreq/rk3399_dmc.c
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -18,14 +18,17 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
>
> +#include
> #include
>
> struct dram_timing {
> @@ -69,8 +72,11 @@ struct rk3399_dmcfreq {
> struct mutex lock;
> struct dram_timing timing;
> struct regulator *vdd_center;
> + struct regmap *regmap_pmu;
> unsigned long rate, target_rate;
> unsigned long volt, target_volt;
> + unsigned int odt_dis_freq;
> + int odt_pd_arg0, odt_pd_arg1;
> };
>
> static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
> @@ -80,6 +86,8 @@ static int rk3399_dmcfreq_target(struct device *dev,
> unsigned long *freq,
> struct dev_pm_opp *opp;
> unsigned long old_clk_rate = dmcfreq->rate;
> unsigned long target_volt, target_rate;
> + struct arm_smccc_res res;
> + bool odt_enable = false;
> int err;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> @@ -95,6 +103,19 @@ static int rk3399_dmcfreq_target(struct device *dev,
> unsigned long *freq,
>
> mutex_lock(>lock);
>
> + if (target_rate >= dmcfreq->odt_dis_freq)
> + odt_enable = true;
> +
> + /*
> + * This makes a SMC call to the TF-A to set the DDR PD (power-down)
> + * timings and to enable or disable the ODT (on-die termination)
> + * resistors.
> + */
> + arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, dmcfreq->odt_pd_arg0,
> + dmcfreq->odt_pd_arg1,
> + ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD,
> + odt_enable, 0, 0, 0, );
> +
> /*
>* If frequency scaling from low to high, adjust voltage first.
>* If frequency scaling from high to low, adjust frequency first.
> @@ -294,11 +315,13 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> {
> struct arm_smccc_res res;
> struct device *dev = >dev;
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.of_node, *node;
> struct rk3399_dmcfreq *data;
> int ret, index, size;
> uint32_t *timing;
> struct dev_pm_opp *opp;
> + u32 ddr_type;
> + u32 val;
>
> data = devm_kzalloc(dev, sizeof(struct rk3399_dmcfreq), GFP_KERNEL);
> if (!data)
> @@ -354,10 +377,56 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> }
> }
>
> + node = of_parse_phandle(np, "rockchip,pmu", 0);
> + if (node) {
> + data->regmap_pmu = syscon_node_to_regmap(node);
> + if (IS_ERR(data->regmap_pmu))
> + return PTR_ERR(data->regmap_pmu);
> + }
> +
> + regmap_read(data->regmap_pmu, RK3399_PMUGRF_OS_REG2, );
> + ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
> + RK3399_PMUGRF_DDRTYPE_MASK;
> +
> + switch (ddr_type) {
> + case RK3399_PMUGRF_DDRTYPE_DDR3:
> + data->odt_dis_freq = data->timing.ddr3_odt_dis_freq;
> + break;
> + case RK3399_PMUGRF_DDRTYPE_LPDDR3:
> + data->odt_dis_freq = data->timing.lpddr3_odt_dis_freq;
> + break;
> + case RK3399_PMUGRF_DDRTYPE_LPDDR4:
> + data->odt_dis_freq = data->timing.lpddr4_odt_dis_freq;
> + break;
>
Re: [PATCH v5 1/6] devfreq: rockchip-dfi: Move GRF definitions to a common place.
Hi Gaël,
The patch1 was already applied to devfreq.git
and then it was applied to linux-pm.git through
pull request of devfreq.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge=adfe3b76608ffe547af5a74415f15499b798f32a
On 19. 5. 3. 오전 2:58, Gaël PORTAY wrote:
> From: Enric Balletbo i Serra
>
> Some rk3399 GRF (Generic Register Files) definitions can be used for
> different drivers. Move these definitions to a common include so we
> don't need to duplicate these definitions.
>
> Signed-off-by: Enric Balletbo i Serra
> Acked-by: Chanwoo Choi
> Signed-off-by: Gaël PORTAY
> Acked-by: MyungJoo Ham
> ---
>
> Changes in v5: None
>
> Changes in v4:
> - [PATCH v3 1/5] Add Acked-by: MyungJoo Ham .
>
> Changes in v3:
> - [PATCH v2 1/5] Add Signed-off-by: Gaël PORTAY .
>
> Changes in v2:
> - [PATCH 1/8] Really add Acked-by: Chanwoo Choi .
>
> Changes in v1:
> - [RFC 1/10] Add Acked-by: Chanwoo Choi
> - [RFC 1/10] s/Generic/General/ (Robin Murphy)
> - [RFC 4/10] Removed from the series. I did not found a use case where not
> holding the mutex causes the issue.
> - [RFC 7/10] Removed from the series. I did not found a use case where this
> matters.
>
> drivers/devfreq/event/rockchip-dfi.c | 23 +++
> include/soc/rockchip/rk3399_grf.h| 21 +
> 2 files changed, 28 insertions(+), 16 deletions(-)
> create mode 100644 include/soc/rockchip/rk3399_grf.h
>
> diff --git a/drivers/devfreq/event/rockchip-dfi.c
> b/drivers/devfreq/event/rockchip-dfi.c
> index 22b113363ffc..2fbbcbeb644f 100644
> --- a/drivers/devfreq/event/rockchip-dfi.c
> +++ b/drivers/devfreq/event/rockchip-dfi.c
> @@ -26,6 +26,8 @@
> #include
> #include
>
> +#include
> +
> #define RK3399_DMC_NUM_CH2
>
> /* DDRMON_CTRL */
> @@ -43,18 +45,6 @@
> #define DDRMON_CH1_COUNT_NUM 0x3c
> #define DDRMON_CH1_DFI_ACCESS_NUM0x40
>
> -/* pmu grf */
> -#define PMUGRF_OS_REG2 0x308
> -#define DDRTYPE_SHIFT13
> -#define DDRTYPE_MASK 7
> -
> -enum {
> - DDR3 = 3,
> - LPDDR3 = 6,
> - LPDDR4 = 7,
> - UNUSED = 0xFF
> -};
> -
> struct dmc_usage {
> u32 access;
> u32 total;
> @@ -83,16 +73,17 @@ static void rockchip_dfi_start_hardware_counter(struct
> devfreq_event_dev *edev)
> u32 ddr_type;
>
> /* get ddr type */
> - regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
> - ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
> + regmap_read(info->regmap_pmu, RK3399_PMUGRF_OS_REG2, );
> + ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
> + RK3399_PMUGRF_DDRTYPE_MASK;
>
> /* clear DDRMON_CTRL setting */
> writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
>
> /* set ddr type to dfi */
> - if (ddr_type == LPDDR3)
> + if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR3)
> writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
> - else if (ddr_type == LPDDR4)
> + else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR4)
> writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
>
> /* enable count, use software mode */
> diff --git a/include/soc/rockchip/rk3399_grf.h
> b/include/soc/rockchip/rk3399_grf.h
> new file mode 100644
> index ..3eebabcb2812
> --- /dev/null
> +++ b/include/soc/rockchip/rk3399_grf.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Rockchip General Register Files definitions
> + *
> + * Copyright (c) 2018, Collabora Ltd.
> + * Author: Enric Balletbo i Serra
> + */
> +
> +#ifndef __SOC_RK3399_GRF_H
> +#define __SOC_RK3399_GRF_H
> +
> +/* PMU GRF Registers */
> +#define RK3399_PMUGRF_OS_REG20x308
> +#define RK3399_PMUGRF_DDRTYPE_SHIFT 13
> +#define RK3399_PMUGRF_DDRTYPE_MASK 7
> +#define RK3399_PMUGRF_DDRTYPE_DDR3 3
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR2 5
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR3 6
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR4 7
> +
> +#endif
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image
> On May 2, 2019, at 4:19 PM, James Morris wrote: > >> On Thu, 2 May 2019, Matthew Garrett wrote: >> >>> On Thu, May 2, 2019 at 2:07 PM James Morris wrote: >>> One possible direction is to (as previously mentioned) assign IDs to each >>> callsite and be able to check this ID against a simple policy array >>> (allow/deny). The default policy choices could be reduced to 'all' or >>> 'none' during kconfig, and allow a custom policy to be loaded later if >>> desired. >> >> Ok. My primary concern around this is that it's very difficult to use >> correctly in anything other than the "all" or "none" modes. If a new >> kernel feature is added with integrated lockdown support, if an admin >> is simply setting the flags of things they wish to block then this >> will be left enabled - and may violate the admin's expectations around >> integrity. On the other hand, if an admin is simply setting the flags >> of things they wish to permit, then adding lockdown support to an >> existing kernel feature may result in that feature suddenly being >> disabled, which may also violate the admin's expectations around the >> flags providing a stable set of behaviour. > > Understood. Most uses will likely be either a distro or an embedded > system, who I'm assuming would provide a useful policy by default, and > perhaps a high-level abstraction for modification. > >> Given that, would you prefer such a policy expression to look like? > > Perhaps a write-once policy, injected from userspace during early boot? > > The policy could be simply a list of: > > lockdown_feature true|false > I’m not convinced this is worthwhile. As I see it, there really are only two privileges here: root can read kernel memory, and root can corrupt kernel state. A policy that root can’t corrupt kernel memory except using, say, eBPF is useless — it gives warm fuzzy feelings but nothing else.
Re: [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support
Hi Dmitry,
On 19. 5. 2. 오전 8:37, Dmitry Osipenko wrote:
> Changelog:
>
> v4: Addressed all review comments that were made by Chanwoo Choi to v3:
>
> - changed the driver removal order to match the probe exactly
> - added clarifying comment for 1/8 ratio to the Tegra20 driver
>
> Chanwoo, please also note that the clk patch that should fix
> compilation problem that was reported the kbuild-test-robot is already
> applied and available in the recent linux-next.
I knew that Stephen picked up your path about clock.
>
> v3: Addressed all review comments that were made by Chanwoo Choi to v2.
>
> Patch "Synchronize IRQ after masking it in hardware" morphed into
> "Properly disable interrupts", which disables interrupts more solidly.
>
> Added new minor patch: "Rename tegra-devfreq.c to tegra30-devfreq.c".
>
> Added missed error handlings for dev_pm_opp_add().
>
> v2: The patchset was quite heavily reworked since v1, few patches we
> dropped or squashed into the new ones and more patches we added.
> In a result more bugs and potential problems are fixed now, driver's
> code got more clean up.
>
> The Tegra20 driver-addition patch is now a part of this series, it has
> no changes since v1.
>
> Dmitry Osipenko (16):
> PM / devfreq: tegra: Fix kHz to Hz conversion
> PM / devfreq: tegra: Replace readl-writel with relaxed versions
> PM / devfreq: tegra: Replace write memory barrier with the read
> barrier
> PM / devfreq: tegra: Don't ignore clk errors
> PM / devfreq: tegra: Don't set EMC clock rate to maximum on probe
> PM / devfreq: tegra: Drop primary interrupt handler
> PM / devfreq: tegra: Properly disable interrupts
> PM / devfreq: tegra: Clean up driver's probe / remove
> PM / devfreq: tegra: Avoid inconsistency of current frequency value
> PM / devfreq: tegra: Mark ACTMON's governor as immutable
> PM / devfreq: tegra: Move governor registration to driver's probe
> PM / devfreq: tegra: Reconfigure hardware on governor's restart
> PM / devfreq: tegra: Support Tegra30
> PM / devfreq: tegra: Enable COMPILE_TEST for the driver
> PM / devfreq: tegra: Rename tegra-devfreq.c to tegra30-devfreq.c
> PM / devfreq: Introduce driver for NVIDIA Tegra20
>
> MAINTAINERS | 8 +
> drivers/devfreq/Kconfig | 15 +-
> drivers/devfreq/Makefile | 3 +-
> drivers/devfreq/tegra20-devfreq.c | 212
> .../{tegra-devfreq.c => tegra30-devfreq.c}| 315 --
> 5 files changed, 379 insertions(+), 174 deletions(-)
> create mode 100644 drivers/devfreq/tegra20-devfreq.c
> rename drivers/devfreq/{tegra-devfreq.c => tegra30-devfreq.c} (81%)
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH 03/11] perf annotate: Fix build on 32 bit for BPF annotation
From: Thadeu Lima de Souza Cascardo
Commit 6987561c9e86 ("perf annotate: Enable annotation of BPF programs") adds
support for BPF programs annotations but the new code does not build on 32-bit.
Signed-off-by: Thadeu Lima de Souza Cascardo
Acked-by: Song Liu
Fixes: 6987561c9e86 ("perf annotate: Enable annotation of BPF programs")
Link: http://lkml.kernel.org/r/20190403194452.10845-1-casca...@canonical.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/annotate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index c8b01176c9e1..09762985c713 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1714,8 +1714,8 @@ static int symbol__disassemble_bpf(struct symbol *sym,
if (dso->binary_type != DSO_BINARY_TYPE__BPF_PROG_INFO)
return -1;
- pr_debug("%s: handling sym %s addr %lx len %lx\n", __func__,
-sym->name, sym->start, sym->end - sym->start);
+ pr_debug("%s: handling sym %s addr %" PRIx64 " len %" PRIx64 "\n",
__func__,
+ sym->name, sym->start, sym->end - sym->start);
memset(tpath, 0, sizeof(tpath));
perf_exe(tpath, sizeof(tpath));
@@ -1740,7 +1740,7 @@ static int symbol__disassemble_bpf(struct symbol *sym,
info_linear = info_node->info_linear;
sub_id = dso->bpf_prog.sub_id;
- info.buffer = (void *)(info_linear->info.jited_prog_insns);
+ info.buffer = (void *)(uintptr_t)(info_linear->info.jited_prog_insns);
info.buffer_length = info_linear->info.jited_prog_len;
if (info_linear->info.nr_line_info)
@@ -1776,7 +1776,7 @@ static int symbol__disassemble_bpf(struct symbol *sym,
const char *srcline;
u64 addr;
- addr = pc + ((u64 *)(info_linear->info.jited_ksyms))[sub_id];
+ addr = pc + ((u64
*)(uintptr_t)(info_linear->info.jited_ksyms))[sub_id];
count = disassemble(pc, );
if (prog_linfo)
--
2.20.1
[PATCH 08/11] perf cs-etm: Always allocate memory for cs_etm_queue::prev_packet
From: Leo Yan
Robert Walker reported a segmentation fault is observed when process
CoreSight trace data; this issue can be easily reproduced by the command
'perf report --itrace=i1000i' for decoding tracing data.
If neither the 'b' flag (synthesize branches events) nor 'l' flag
(synthesize last branch entries) are specified to option '--itrace',
cs_etm_queue::prev_packet will not been initialised. After merging the
code to support exception packets and sample flags, there introduced a
number of uses of cs_etm_queue::prev_packet without checking whether it
is valid, for these cases any accessing to uninitialised prev_packet
will cause crash.
As cs_etm_queue::prev_packet is used more widely now and it's already
hard to follow which functions have been called in a context where the
validity of cs_etm_queue::prev_packet has been checked, this patch
always allocates memory for cs_etm_queue::prev_packet.
Reported-by: Robert Walker
Suggested-by: Robert Walker
Signed-off-by: Leo Yan
Tested-by: Robert Walker
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Namhyung Kim
Cc: Suzuki K Poulouse
Cc: linux-arm-ker...@lists.infradead.org
Fixes: 7100b12cf474 ("perf cs-etm: Generate branch sample for exception packet")
Fixes: 24fff5eb2b93 ("perf cs-etm: Avoid stale branch samples when flush
packet")
Link: http://lkml.kernel.org/r/20190428083228.20246-1-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/cs-etm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index cfc1ad8c..de488b43f440 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -422,11 +422,9 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct
cs_etm_auxtrace *etm)
if (!etmq->packet)
goto out_free;
- if (etm->synth_opts.last_branch || etm->sample_branches) {
- etmq->prev_packet = zalloc(szp);
- if (!etmq->prev_packet)
- goto out_free;
- }
+ etmq->prev_packet = zalloc(szp);
+ if (!etmq->prev_packet)
+ goto out_free;
if (etm->synth_opts.last_branch) {
size_t sz = sizeof(struct branch_stack);
--
2.20.1
[PATCH 11/11] perf tools: Remove needless asm/unistd.h include fixing build in some places
From: Arnaldo Carvalho de Melo We were including sys/syscall.h and asm/unistd.h, since sys/syscall.h includes asm/unistd.h, sometimes this leads to the redefinition of defines, breaking the build. Noticed on ARC with uCLibc. Cc: Adrian Hunter Cc: Arnaldo Carvalho de Melo Cc: Arnd Bergmann Cc: Jiri Olsa Cc: Namhyung Kim Cc: Rich Felker Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-xjpf80o64i2ko74aj2jih...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/cloexec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c index ca0fff6272be..06f48312c5ed 100644 --- a/tools/perf/util/cloexec.c +++ b/tools/perf/util/cloexec.c @@ -7,7 +7,6 @@ #include "asm/bug.h" #include "debug.h" #include -#include #include static unsigned long flag = PERF_FLAG_FD_CLOEXEC; -- 2.20.1
[PATCH 09/11] tools build: Add -ldl to the disassembler-four-args feature test
From: Arnaldo Carvalho de Melo Thomas Backlund reported that the perf build was failing on the Mageia 7 distro, that is because it uses: cat /tmp/build/perf/feature/test-disassembler-four-args.make.output /usr/bin/ld: /usr/lib64/libbfd.a(plugin.o): in function `try_load_plugin': /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:243: undefined reference to `dlopen' /usr/bin/ld: /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:271: undefined reference to `dlsym' /usr/bin/ld: /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:256: undefined reference to `dlclose' /usr/bin/ld: /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:246: undefined reference to `dlerror' as we allow dynamic linking and loading Mageia 7 uses these linker flags: $ rpm --eval %ldflags -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags So add -ldl to this feature LDFLAGS. Reported-by: Thomas Backlund Tested-by: Thomas Backlund Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Cc: Song Liu Link: https://lkml.kernel.org/r/20190501173158.gc21...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index fe3f97e342fa..6d65874e16c3 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -227,7 +227,7 @@ FEATURE_CHECK_LDFLAGS-libpython-version := $(PYTHON_EMBED_LDOPTS) FEATURE_CHECK_LDFLAGS-libaio = -lrt -FEATURE_CHECK_LDFLAGS-disassembler-four-args = -lbfd -lopcodes +FEATURE_CHECK_LDFLAGS-disassembler-four-args = -lbfd -lopcodes -ldl CFLAGS += -fno-omit-frame-pointer CFLAGS += -ggdb3 -- 2.20.1
[PATCH 07/11] perf cs-etm: Don't check cs_etm_queue::prev_packet validity
From: Leo Yan
Since cs_etm_queue::prev_packet is allocated for all cases, it will
never be NULL pointer; now validity checking prev_packet is pointless,
remove all of them.
Signed-off-by: Leo Yan
Tested-by: Robert Walker
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Namhyung Kim
Cc: Suzuki K Poulouse
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20190428083228.20246-2-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/cs-etm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 110804936fc3..cfc1ad8c 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -981,7 +981,6 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
* PREV_PACKET is a branch.
*/
if (etm->synth_opts.last_branch &&
- etmq->prev_packet &&
etmq->prev_packet->sample_type == CS_ETM_RANGE &&
etmq->prev_packet->last_instr_taken_branch)
cs_etm__update_last_branch_rb(etmq);
@@ -1014,7 +1013,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
etmq->period_instructions = instrs_over;
}
- if (etm->sample_branches && etmq->prev_packet) {
+ if (etm->sample_branches) {
bool generate_sample = false;
/* Generate sample for tracing on packet */
@@ -1071,9 +1070,6 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
struct cs_etm_auxtrace *etm = etmq->etm;
struct cs_etm_packet *tmp;
- if (!etmq->prev_packet)
- return 0;
-
/* Handle start tracing packet */
if (etmq->prev_packet->sample_type == CS_ETM_EMPTY)
goto swap_packet;
--
2.20.1
[PATCH 06/11] perf report: Report OOM in status line in the GTK UI
From: Thomas Richter
An -ENOMEM error is not reported in the GTK GUI. Instead this error
message pops up on the screen:
[root@m35lp76 perf]# ./perf report -i perf.data.error68-1
Processing events... [974K/3M]
Error:failed to process sample
0xf4198 [0x8]: failed to process type: 68
However when I use the same perf.data file with --stdio it works:
[root@m35lp76 perf]# ./perf report -i perf.data.error68-1 --stdio \
| head -12
# Total Lost Samples: 0
#
# Samples: 76K of event 'cycles'
# Event count (approx.): 9905616
#
# Overhead Command Shared Object Symbol
# ... . .
#
8.81% find [kernel.kallsyms] [k] ftrace_likely_update
8.74% swapper [kernel.kallsyms] [k] ftrace_likely_update
8.34% sshd [kernel.kallsyms] [k] ftrace_likely_update
2.19% kworker/u512:1- [kernel.kallsyms] [k] ftrace_likely_update
The sample precentage is a bit low.
The GUI always fails in the FINISHED_ROUND event (68) and does not
indicate the reason why.
When happened is the following. Perf report calls a lot of functions and
down deep when a FINISHED_ROUND event is processed, these functions are
called:
perf_session__process_event()
+ perf_session__process_user_event()
+ process_finished_round()
+ ordered_events__flush()
+ __ordered_events__flush()
+ do_flush()
+ ordered_events__deliver_event()
+ perf_session__deliver_event()
+ machine__deliver_event()
+ perf_evlist__deliver_event()
+ process_sample_event()
+ hist_entry_iter_add() --> only called in GUI case!!!
+ hist_iter__report__callback()
+ symbol__inc_addr_sample()
Now this functions runs out of memory and
returns -ENOMEM. This is reported all the way up
until function
perf_session__process_event() returns to its caller, where -ENOMEM is
changed to -EINVAL and processing stops:
if ((skip = perf_session__process_event(session, event, head)) < 0) {
pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
head, event->header.size, event->header.type);
err = -EINVAL;
goto out_err;
}
This occurred in the FINISHED_ROUND event when it has to process some
1 entries and ran out of memory.
This patch indicates the root cause and displays it in the status line
of ther perf report GUI.
Output before (on GUI status line):
0xf4198 [0x8]: failed to process type: 68
Output after:
0xf4198 [0x8]: failed to process type: 68 [not enough memory]
Committer notes:
the 'skip' variable needs to be initialized to -EINVAL, so that when the
size is less than sizeof(struct perf_event_attr) we avoid this valid
compiler warning:
util/session.c: In function ‘perf_session__process_events’:
util/session.c:1936:7: error: ‘skip’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
err = skip;
^~
util/session.c:1874:6: note: ‘skip’ was declared here
s64 skip;
^~~~
cc1: all warnings being treated as errors
Signed-off-by: Thomas Richter
Reviewed-by: Hendrik Brueckner
Reviewed-by: Jiri Olsa
Cc: Heiko Carstens
Cc: Martin Schwidefsky
Link: http://lkml.kernel.org/r/20190423105303.61683-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/session.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index b17f1c9bc965..bad5f87ae001 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1928,12 +1928,14 @@ reader__process_events(struct reader *rd, struct
perf_session *session,
size = event->header.size;
+ skip = -EINVAL;
+
if (size < sizeof(struct perf_event_header) ||
(skip = rd->process(session, event, file_pos)) < 0) {
- pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
+ pr_err("%#" PRIx64 " [%#x]: failed to process type: %d [%s]\n",
file_offset + head, event->header.size,
- event->header.type);
- err = -EINVAL;
+ event->header.type, strerror(-skip));
+ err = skip;
goto out;
}
--
2.20.1
[PATCH 02/11] tools uapi x86: Sync vmx.h with the kernel
From: Arnaldo Carvalho de Melo
To pick up the changes from:
2b27924bb1d4 ("KVM: nVMX: always use early vmcs check when EPT is disabled")
That causes this object in the tools/perf build process to be rebuilt:
CC /tmp/build/perf/arch/x86/util/kvm-stat.o
But it isn't using VMX_ABORT_ prefixed constants, so no change in
behaviour.
This silences this perf build warning:
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' differs
from latest version at 'arch/x86/include/uapi/asm/vmx.h'
diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paolo Bonzini
Link: https://lkml.kernel.org/n/tip-bjbo3zc0r8i8oa0udpvft...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/arch/x86/include/uapi/asm/vmx.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/arch/x86/include/uapi/asm/vmx.h
b/tools/arch/x86/include/uapi/asm/vmx.h
index f0b0c90dd398..d213ec5c3766 100644
--- a/tools/arch/x86/include/uapi/asm/vmx.h
+++ b/tools/arch/x86/include/uapi/asm/vmx.h
@@ -146,6 +146,7 @@
#define VMX_ABORT_SAVE_GUEST_MSR_FAIL1
#define VMX_ABORT_LOAD_HOST_PDPTE_FAIL 2
+#define VMX_ABORT_VMCS_CORRUPTED 3
#define VMX_ABORT_LOAD_HOST_MSR_FAIL 4
#endif /* _UAPIVMX_H */
--
2.20.1
[PATCH 04/11] tools lib traceevent: Change tag string for error
From: Leo Yan
The traceevent lib is used by the perf tool, and when executing
perf test -v 6
it outputs error log on the ARM64 platform:
running test 33 '*:*'trace-cmd: No such file or directory
[...]
trace-cmd: Invalid argument
The trace event parsing code originally came from trace-cmd so it keeps
the tag string "trace-cmd" for errors, this easily introduces the
impression that the perf tool launches trace-cmd command for trace event
parsing, but in fact the related parsing is accomplished by the
traceevent lib.
This patch changes the tag string to "libtraceevent" so that we can
avoid confusion and let users to more easily connect the error with
traceevent lib.
Signed-off-by: Leo Yan
Acked-by: Steven Rostedt (VMware)
Link: http://lkml.kernel.org/r/20190424013802.27569-1-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/parse-utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/traceevent/parse-utils.c
b/tools/lib/traceevent/parse-utils.c
index 77e4ec6402dd..e99867111387 100644
--- a/tools/lib/traceevent/parse-utils.c
+++ b/tools/lib/traceevent/parse-utils.c
@@ -14,7 +14,7 @@
void __vwarning(const char *fmt, va_list ap)
{
if (errno)
- perror("trace-cmd");
+ perror("libtraceevent");
errno = 0;
fprintf(stderr, " ");
--
2.20.1
[GIT PULL 00/11] perf/urgent fixes
From: Arnaldo Carvalho de Melo
Hi Ingo,
This took a bit more time than I expected as I'm traveling,
LSF/MM + BPF, and also some of the fixes I worked on and off while on my
way here needed tweaks,
Thanks,
- Arnaldo
Test results at the end of this message, as usual.
The following changes since commit 1804569d87de903b4d746ba71512c3ed0a890d65:
MAINTAINERS: Include vendor specific files under arch/*/events/* (2019-05-02
18:28:12 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tags/perf-urgent-for-mingo-5.1-20190502
for you to fetch changes up to 7e221b811f1472d0c58c7d4e0fe84fcacd22580a:
perf tools: Remove needless asm/unistd.h include fixing build in some places
(2019-05-02 16:00:20 -0400)
perf/urgent fixes:
tools UAPI:
Arnaldo Carvalho de Melo:
- Sync x86's vmx.h with the kernel.
- Copy missing unistd.h headers for arc, hexagon and riscv, fixing
a reported build regression on the ARC 32-bit architecture.
perf bench numa:
Arnaldo Carvalho de Melo:
- Add define for RUSAGE_THREAD if not present, fixing the build on the
ARC architecture when only zlib and libnuma are present.
perf BPF:
Arnaldo Carvalho de Melo:
- The disassembler-four-args feature test needs -ldl on distros such as
Mageia 7.
Bo YU:
- Fix unlocking on success in perf_env__find_btf(), detected with
the coverity tool.
libtraceevent:
Leo Yan:
- Change misleading hard coded 'trace-cmd' string in error messages.
ARM hardware tracing:
Leo Yan:
- Always allocate memory for cs_etm_queue::prev_packet, fixing a segfault
when processing CoreSight perf data.
perf annotate:
Thadeu Lima de Souza Cascardo:
- Fix build on 32 bit for BPF.
perf report:
Thomas Richter:
- Report OOM in status line in the GTK UI.
core libs:
- Remove needless asm/unistd.h that, used with sys/syscall.h ended
up redefining the syscalls defines in environments such as the
ARC arch when using uClibc.
Signed-off-by: Arnaldo Carvalho de Melo
Arnaldo Carvalho de Melo (5):
tools uapi x86: Sync vmx.h with the kernel
perf bench numa: Add define for RUSAGE_THREAD if not present
tools build: Add -ldl to the disassembler-four-args feature test
tools arch uapi: Copy missing unistd.h headers for arc, hexagon and riscv
perf tools: Remove needless asm/unistd.h include fixing build in some
places
Bo YU (1):
perf bpf: Return value with unlocking in perf_env__find_btf()
Leo Yan (3):
tools lib traceevent: Change tag string for error
perf cs-etm: Don't check cs_etm_queue::prev_packet validity
perf cs-etm: Always allocate memory for cs_etm_queue::prev_packet
Thadeu Lima de Souza Cascardo (1):
perf annotate: Fix build on 32 bit for BPF annotation
Thomas Richter (1):
perf report: Report OOM in status line in the GTK UI
tools/arch/arc/include/uapi/asm/unistd.h | 51
tools/arch/hexagon/include/uapi/asm/unistd.h | 40 ++
tools/arch/riscv/include/uapi/asm/unistd.h | 42 +++
tools/arch/x86/include/uapi/asm/vmx.h| 1 +
tools/lib/traceevent/parse-utils.c | 2 +-
tools/perf/Makefile.config | 2 +-
tools/perf/bench/numa.c | 4 +++
tools/perf/util/annotate.c | 8 ++---
tools/perf/util/cloexec.c| 1 -
tools/perf/util/cs-etm.c | 14 +++-
tools/perf/util/env.c| 2 +-
tools/perf/util/session.c| 8 +++--
12 files changed, 154 insertions(+), 21 deletions(-)
create mode 100644 tools/arch/arc/include/uapi/asm/unistd.h
create mode 100644 tools/arch/hexagon/include/uapi/asm/unistd.h
create mode 100644 tools/arch/riscv/include/uapi/asm/unistd.h
Test results:
The first ones are container based builds of tools/perf with and without libelf
support. Where clang is available, it is also used to build perf with/without
libelf, and building with LIBCLANGLLVM=1 (built-in clang) with gcc and clang
when clang and its devel libraries are installed.
The objtool and samples/bpf/ builds are disabled now that I'm switching from
using the sources in a local volume to fetching them from a http server to
build it inside the container, to make it easier to build in a container
cluster.
Those will come back later.
Several are cross builds, the ones with -x-ARCH and the android one, and those
may not have all the features built, due to lack of multi-arch devel packages,
available and being used so far on just a few, like
debian:experimental-x-{arm64,mipsel}.
The 'perf test' one will perform a variety of tests exercising
tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands
with a variety
linux-next: build warning after merge of the btrfs-kdave tree
Hi David,
After merging the btrfs-kdave tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
fs/btrfs/props.c: In function 'inherit_props':
fs/btrfs/props.c:389:4: warning: 'num_bytes' may be used uninitialized in this
function [-Wmaybe-uninitialized]
btrfs_block_rsv_release(fs_info, trans->block_rsv,
^~
num_bytes);
~~
Probably introduced by commit
b835a4a3faec ("btrfs: use the existing reserved items for our first prop for
inheritance")
Looks like a false positive to me.
--
Cheers,
Stephen Rothwell
pgpdldbKSyEi4.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH v2 11/17] sched: Basic tracking of matching tasks
On 5/1/19 4:27 PM, Tim Chen wrote:
> On 4/28/19 11:15 PM, Aaron Lu wrote:
>> On Tue, Apr 23, 2019 at 04:18:16PM +, Vineeth Remanan Pillai wrote:
>>> +/*
>>> + * Find left-most (aka, highest priority) task matching @cookie.
>>> + */
>>> +struct task_struct *sched_core_find(struct rq *rq, unsigned long cookie)
>>> +{
>>> + struct rb_node *node = rq->core_tree.rb_node;
>>> + struct task_struct *node_task, *match;
>>> +
>>> + /*
>>> +* The idle task always matches any cookie!
>>> +*/
>>> + match = idle_sched_class.pick_task(rq);
>>> +
>>> + while (node) {
>>> + node_task = container_of(node, struct task_struct, core_node);
>>> +
>>> + if (node_task->core_cookie < cookie) {
>>> + node = node->rb_left;
>>
>> Should go right here?
>>
>
> I think Aaron is correct. We order the rb tree where tasks with smaller core
> cookies
> go to the left part of the tree.
>
> In this case, the cookie we are looking for is larger than the current node's
> cookie.
> It seems like we should move to the right to look for a node with matching
> cookie.
>
> At least making the following change still allow us to run the system stably
> for sysbench.
> Need to gather more data to see how performance changes.
Pawan ran an experiment setting up 2 VMs, with one VM doing a parallel kernel
build and one VM doing sysbench,
limiting both VMs to run on 16 cpu threads (8 physical cores), with 8 vcpu for
each VM.
Making the fix did improve kernel build time by 7%.
Tim
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 25638a47c408..ed4cfa49e3f2 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -208,9 +208,9 @@ static struct task_struct *sched_core_find(struct rq *rq,
> unsigned long cookie)
> while (node) {
> node_task = container_of(node, struct task_struct, core_node);
>
> - if (node_task->core_cookie < cookie) {
> + if (cookie < node_task->core_cookie) {
> node = node->rb_left;
> - } else if (node_task->core_cookie > cookie) {
> + } else if (cookie > node_task->core_cookie) {
> node = node->rb_right;
> } else {
> match = node_task;
>
>
Re: [PATCH 4.14 00/49] 4.14.116-stable review
stable-rc/linux-4.14.y boot: 122 boots: 1 failed, 121 passed (v4.14.115-50-ga4aa5bff0752) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.115-50-ga4aa5bff0752/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.115-50-ga4aa5bff0752/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.115-50-ga4aa5bff0752 Git Commit: a4aa5bff075214a024ba945abb791813e33860ac Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 65 unique boards, 24 SoC families, 14 builds out of 201 Boot Failure Detected: arm64: defconfig: gcc-7: rk3399-firefly: 1 failed lab --- For more info write to
Re: Strange issues with epoll since 5.0
Eric,
Can you please help test this?
If this solves your problem, I can post the fix.
Thanks,
- Deepa
-8<---
Subject: [PATCH] signal: Adjust error codes according to restore_user_sigmask()
For all the syscalls that receive a sigmask from the userland,
the user sigmask is to be in effect through the syscall execution.
At the end of syscall, sigmask of the current process is restored
to what it was before the switch over to user sigmask.
But, for this to be true in practice, the sigmask should be restored
only at the the point we change the saved_sigmask. Anything before
that loses signals. And, anything after is just pointless as the
signal is already lost by restoring the sigmask.
The issue was detected because of a regression caused by 854a6ed56839a.
The patch moved the signal_pending() check closer to restoring of the
user sigmask. But, it failed to update the error code accordingly.
Detailed issue discussion permalink:
https://lore.kernel.org/linux-fsdevel/20190427093319.sgicqik2oqkez3wk@dcvr/
Note that the patch returns interrupted errors (EINTR, ERESTARTNOHAND, etc)
only when there is no other error. If there is a signal and an error like
EINVAL, the syscalls return -EINVAL rather than the interrupted error codes.
Reported-by: Omar Kilani
Reported-by: Eric Wong
Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
restore_user_sigmask()")
Signed-off-by: Deepa Dinamani
---
fs/aio.c | 24
fs/eventpoll.c | 14 ++
fs/io_uring.c | 9 ++---
fs/select.c| 37 +
include/linux/signal.h | 2 +-
kernel/signal.c| 8 +---
6 files changed, 55 insertions(+), 39 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 38b741aef0bf..7de2f7573d55 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -2133,7 +2133,7 @@ SYSCALL_DEFINE6(io_pgetevents,
struct __aio_sigsetksig = { NULL, };
sigset_tksigmask, sigsaved;
struct timespec64ts;
-int ret;
+int ret, signal_detected;
if (timeout && unlikely(get_timespec64(, timeout)))
return -EFAULT;
@@ -2146,8 +2146,8 @@ SYSCALL_DEFINE6(io_pgetevents,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
-restore_user_sigmask(ksig.sigmask, );
-if (signal_pending(current) && !ret)
+signal_detected = restore_user_sigmask(ksig.sigmask, );
+if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
@@ -2166,7 +2166,7 @@ SYSCALL_DEFINE6(io_pgetevents_time32,
struct __aio_sigsetksig = { NULL, };
sigset_tksigmask, sigsaved;
struct timespec64ts;
-int ret;
+int ret, signal_detected;
if (timeout && unlikely(get_old_timespec32(, timeout)))
return -EFAULT;
@@ -2180,8 +2180,8 @@ SYSCALL_DEFINE6(io_pgetevents_time32,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
-restore_user_sigmask(ksig.sigmask, );
-if (signal_pending(current) && !ret)
+signal_detected = restore_user_sigmask(ksig.sigmask, );
+if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
@@ -2231,7 +2231,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents,
struct __compat_aio_sigset ksig = { NULL, };
sigset_t ksigmask, sigsaved;
struct timespec64 t;
-int ret;
+int ret, signal_detected;
if (timeout && get_old_timespec32(, timeout))
return -EFAULT;
@@ -2244,8 +2244,8 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
-restore_user_sigmask(ksig.sigmask, );
-if (signal_pending(current) && !ret)
+signal_detected = restore_user_sigmask(ksig.sigmask, );
+if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
@@ -2264,7 +2264,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents_time64,
struct __compat_aio_sigset ksig = { NULL, };
sigset_t ksigmask, sigsaved;
struct timespec64 t;
-int ret;
+int ret, signal_detected;
if (timeout && get_timespec64(, timeout))
return -EFAULT;
@@ -2277,8 +2277,8 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents_time64,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
-restore_user_sigmask(ksig.sigmask, );
-if (signal_pending(current) && !ret)
+signal_detected = restore_user_sigmask(ksig.sigmask, );
+if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 4a0e98d87fcc..fe5a0724b417 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -2317,7 +2317,7 @@ SYSCALL_DEFINE6(epoll_pwait, int, epfd, struct
epoll_event __user *, events,
int, maxevents, int, timeout, const sigset_t __user *, sigmask,
size_t, sigsetsize)
{
-int error;
+int error, signal_detected;
sigset_t
Re: [PATCH] perf vendor events arm64: Map Brahma-B53 CPUID to cortex-a53 events
Em Thu, May 02, 2019 at 02:28:02PM -0700, Florian Fainelli escreveu: > On 4/8/19 9:26 AM, Will Deacon wrote: > > On Fri, Apr 05, 2019 at 09:50:47AM -0700, Florian Fainelli wrote: > >> Broadcom's Brahma-B53 CPUs support the same type of events that the > >> Cortex-A53 supports, recognize its CPUID and map it to the cortex-a53 > >> events. > >> > >> Signed-off-by: Florian Fainelli > >> --- > >> tools/perf/pmu-events/arch/arm64/mapfile.csv | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/tools/perf/pmu-events/arch/arm64/mapfile.csv > >> b/tools/perf/pmu-events/arch/arm64/mapfile.csv > >> index 59cd8604b0bd..e97c12484bc6 100644 > >> --- a/tools/perf/pmu-events/arch/arm64/mapfile.csv > >> +++ b/tools/perf/pmu-events/arch/arm64/mapfile.csv > >> @@ -13,6 +13,7 @@ > >> # > >> #Family-model,Version,Filename,EventType > >> 0x410fd03[[:xdigit:]],v1,arm/cortex-a53,core > >> +0x420f100[[:xdigit:]],v1,arm/cortex-a53,core > >> 0x420f5160,v1,cavium/thunderx2,core > >> 0x430f0af0,v1,cavium/thunderx2,core > >> 0x480fd010,v1,hisilicon/hip08,core > > > > Acked-by: Will Deacon > > Thanks! Can this be picked up? Thanks, applied to perf/core. - Arnaldo
Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions
On Thu, 2 May 2019 19:31:29 -0400
Steven Rostedt wrote:
> Digging a little further, I pinpointed it out to being kretprobes. The
> problem I believe is the use of kernel_stack_pointer() which does some
> magic on x86_32. kretprobes uses this to hijack the return address of
> the function (much like the function graph tracer does). I do have code
> that would allow kretprobes to use the function graph tracer instead,
> but that's still in progress (almost done!). But still, we should not
> have this break the use of kernel_stack_pointer() either.
>
> Adding some printks in that code, it looks to be returning ">sp"
> which I think we changed.
>
This appears to fix it!
-- Steve
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 4b8ee05dd6ad..600ead178bf4 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -171,8 +171,12 @@ unsigned long kernel_stack_pointer(struct pt_regs *regs)
unsigned long sp = (unsigned long)>sp;
u32 *prev_esp;
- if (context == (sp & ~(THREAD_SIZE - 1)))
+ if (context == (sp & ~(THREAD_SIZE - 1))) {
+ /* int3 code adds a gap */
+ if (sp == regs->sp - 5*4)
+ return regs->sp;
return sp;
+ }
prev_esp = (u32 *)(context);
if (*prev_esp)
[PATCH v2] perf vendor events arm64: Add Cortex-A57 and Cortex-A72 events
The Cortex-A57 and Cortex-A72 both support all ARMv8 recommended events
up to the RC_ST_SPEC (0x91) event with the exception of:
- L1D_CACHE_REFILL_INNER (0x44)
- L1D_CACHE_REFILL_OUTER (0x45)
- L1D_TLB_RD (0x4E)
- L1D_TLB_WR (0x4F)
- L2D_TLB_REFILL_RD (0x5C)
- L2D_TLB_REFILL_WR (0x5D)
- L2D_TLB_RD (0x5E)
- L2D_TLB_WR (0x5F)
- STREX_SPEC (0x6F)
Create an appropriate JSON file for mapping those events and update the
mapfile.csv for matching the Cortex-A57 and Cortex-A72 MIDR to that
file.
Signed-off-by: Florian Fainelli
---
Changes in v2:
- added a shared directory for both Cortex-A57 and A72 (Will)
- removed unsupported ARMv8 v3 events (John)
.../arm/cortex-a57-a72/core-imp-def.json | 179 ++
tools/perf/pmu-events/arch/arm64/mapfile.csv | 2 +
2 files changed, 181 insertions(+)
create mode 100644
tools/perf/pmu-events/arch/arm64/arm/cortex-a57-a72/core-imp-def.json
diff --git
a/tools/perf/pmu-events/arch/arm64/arm/cortex-a57-a72/core-imp-def.json
b/tools/perf/pmu-events/arch/arm64/arm/cortex-a57-a72/core-imp-def.json
new file mode 100644
index ..0ac9b7927450
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/arm/cortex-a57-a72/core-imp-def.json
@@ -0,0 +1,179 @@
+[
+{
+"ArchStdEvent": "L1D_CACHE_RD",
+},
+{
+"ArchStdEvent": "L1D_CACHE_WR",
+},
+{
+"ArchStdEvent": "L1D_CACHE_REFILL_RD",
+},
+{
+"ArchStdEvent": "L1D_CACHE_REFILL_WR",
+},
+{
+"ArchStdEvent": "L1D_CACHE_WB_VICTIM",
+},
+{
+"ArchStdEvent": "L1D_CACHE_WB_CLEAN",
+},
+{
+"ArchStdEvent": "L1D_CACHE_INVAL",
+},
+{
+"ArchStdEvent": "L1D_TLB_REFILL_RD",
+},
+{
+"ArchStdEvent": "L1D_TLB_REFILL_WR",
+},
+{
+"ArchStdEvent": "L2D_CACHE_RD",
+},
+{
+"ArchStdEvent": "L2D_CACHE_WR",
+},
+{
+"ArchStdEvent": "L2D_CACHE_REFILL_RD",
+},
+{
+"ArchStdEvent": "L2D_CACHE_REFILL_WR",
+},
+{
+"ArchStdEvent": "L2D_CACHE_WB_VICTIM",
+},
+{
+"ArchStdEvent": "L2D_CACHE_WB_CLEAN",
+},
+{
+"ArchStdEvent": "L2D_CACHE_INVAL",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_RD",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_WR",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_SHARED",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_NOT_SHARED",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_NORMAL",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_PERIPH",
+},
+{
+"ArchStdEvent": "MEM_ACCESS_RD",
+},
+{
+"ArchStdEvent": "MEM_ACCESS_WR",
+},
+{
+"ArchStdEvent": "UNALIGNED_LD_SPEC",
+},
+{
+"ArchStdEvent": "UNALIGNED_ST_SPEC",
+},
+{
+"ArchStdEvent": "UNALIGNED_LDST_SPEC",
+},
+{
+"ArchStdEvent": "LDREX_SPEC",
+},
+{
+"ArchStdEvent": "STREX_PASS_SPEC",
+},
+{
+"ArchStdEvent": "STREX_FAIL_SPEC",
+},
+{
+"ArchStdEvent": "LD_SPEC",
+},
+{
+"ArchStdEvent": "ST_SPEC",
+},
+{
+"ArchStdEvent": "LDST_SPEC",
+},
+{
+"ArchStdEvent": "DP_SPEC",
+},
+{
+"ArchStdEvent": "ASE_SPEC",
+},
+{
+"ArchStdEvent": "VFP_SPEC",
+},
+{
+"ArchStdEvent": "PC_WRITE_SPEC",
+},
+{
+"ArchStdEvent": "CRYPTO_SPEC",
+},
+{
+"ArchStdEvent": "BR_IMMED_SPEC",
+},
+{
+"ArchStdEvent": "BR_RETURN_SPEC",
+},
+{
+"ArchStdEvent": "BR_INDIRECT_SPEC",
+},
+{
+"ArchStdEvent": "ISB_SPEC",
+},
+{
+"ArchStdEvent": "DSB_SPEC",
+},
+{
+"ArchStdEvent": "DMB_SPEC",
+},
+{
+"ArchStdEvent": "EXC_UNDEF",
+},
+{
+"ArchStdEvent": "EXC_SVC",
+},
+{
+"ArchStdEvent": "EXC_PABORT",
+},
+{
+"ArchStdEvent": "EXC_DABORT",
+},
+{
+"ArchStdEvent": "EXC_IRQ",
+},
+{
+"ArchStdEvent": "EXC_FIQ",
+},
+{
+"ArchStdEvent": "EXC_SMC",
+},
+{
+"ArchStdEvent": "EXC_HVC",
+},
+{
+"ArchStdEvent": "EXC_TRAP_PABORT",
+},
+{
+"ArchStdEvent": "EXC_TRAP_DABORT",
+},
+{
+"ArchStdEvent": "EXC_TRAP_OTHER",
+},
+{
+"ArchStdEvent": "EXC_TRAP_IRQ",
+},
+{
+"ArchStdEvent": "EXC_TRAP_FIQ",
+},
+{
+"ArchStdEvent": "RC_LD_SPEC",
+},
+{
+"ArchStdEvent": "RC_ST_SPEC",
+},
+]
diff --git a/tools/perf/pmu-events/arch/arm64/mapfile.csv
b/tools/perf/pmu-events/arch/arm64/mapfile.csv
index 59cd8604b0bd..69a73957e35c 100644
--- a/tools/perf/pmu-events/arch/arm64/mapfile.csv
+++ b/tools/perf/pmu-events/arch/arm64/mapfile.csv
@@ -13,6 +13,8 @@
#
#Family-model,Version,Filename,EventType
0x410fd03[[:xdigit:]],v1,arm/cortex-a53,core
Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions
On Thu, 2 May 2019 18:52:25 -0400 Steven Rostedt wrote: > On Thu, 2 May 2019 22:21:46 +0200 > Peter Zijlstra wrote: > > > On Thu, May 02, 2019 at 11:43:37AM -0700, Linus Torvalds wrote: > > > What would it look like with the "int3-from-kernel is special" > > > modification? > > > > Something like so; it boots; but I could've made some horrible mistake > > (again). > > > > --- > > diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S > > index 7b23431be5cb..4de51cff5b8a 100644 > > --- a/arch/x86/entry/entry_32.S > > +++ b/arch/x86/entry/entry_32.S > > Oh, and so close! > > I was running this on my i386 tests and for test 8 of 9 (passed 1-7) I > hit this: Digging a little further, I pinpointed it out to being kretprobes. The problem I believe is the use of kernel_stack_pointer() which does some magic on x86_32. kretprobes uses this to hijack the return address of the function (much like the function graph tracer does). I do have code that would allow kretprobes to use the function graph tracer instead, but that's still in progress (almost done!). But still, we should not have this break the use of kernel_stack_pointer() either. Adding some printks in that code, it looks to be returning ">sp" which I think we changed. -- Steve
Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
On Thu, May 02 2019, Andreas Gruenbacher wrote: > On Thu, 2 May 2019 at 05:57, NeilBrown wrote: >> On Wed, May 01 2019, Amir Goldstein wrote: >> > On Wed, May 1, 2019 at 10:03 PM NeilBrown wrote: >> >> On Tue, Dec 06 2016, J. Bruce Fields wrote: >> >> > On Tue, Dec 06, 2016 at 02:18:31PM +0100, Andreas Gruenbacher wrote: >> >> >> On Tue, Dec 6, 2016 at 11:08 AM, Miklos Szeredi >> >> >> wrote: >> >> >> > On Tue, Dec 6, 2016 at 12:24 AM, Andreas Grünbacher >> >> >> > wrote: >> >> >> >> 2016-12-06 0:19 GMT+01:00 Andreas Grünbacher >> >> >> >> : >> >> >> > >> >> >> >>> It's not hard to come up with a heuristic that determines if a >> >> >> >>> system.nfs4_acl value is equivalent to a file mode, and to ignore >> >> >> >>> the >> >> >> >>> attribute in that case. (The file mode is transmitted in its own >> >> >> >>> attribute already, so actually converting .) That way, overlayfs >> >> >> >>> could >> >> >> >>> still fail copying up files that have an actual ACL. It's still an >> >> >> >>> ugly hack ... >> >> >> >> >> >> >> >> Actually, that kind of heuristic would make sense in the NFS client >> >> >> >> which could then hide the "system.nfs4_acl" attribute. > > I still think the nfs client could make this problem mostly go away by > not exposing "system.nfs4_acl" xattrs when the acl is equivalent to > the file mode. Maybe ... but this feels a bit like "sweeping it under the carpet". What happens if some file on the lower layer does have a more complex ACL? Do we just fail any attempt to modify that object? Doesn't that violate the law of least surprise? Maybe if the lower-layer has an i_op->permission method, then overlayfs should *always* call that for permission checking - unless a chmod/chown/etc has happened on the file. That way, we wouldn't need to copy-up the ACL, but would still get correct ACL testing. Thanks, NeilBrown > The richacl patches contain a workable abgorithm for > that. The problem would remain for files that have an actual NFS4 ACL, > which just cannot be mapped to a file mode or to POSIX ACLs in the > general case, as well as for files that have a POSIX ACL. Mapping NFS4 > ACL that used to be a POSIX ACL back to POSIX ACLs could be achieved > in many cases as well, but the code would be quite messy. A better way > seems to be to using a filesystem that doesn't support POSIX ACLs in > the first place. Unfortunately, xfs doesn't allow turning off POSIX > ACLs, for example. > > Andreas > >> >> >> > Even simpler would be if knfsd didn't send the attribute if not >> >> >> > necessary. Looks like there's code actively creating the nfs4_acl on >> >> >> > the wire even if the filesystem had none: >> >> >> > >> >> >> > pacl = get_acl(inode, ACL_TYPE_ACCESS); >> >> >> > if (!pacl) >> >> >> > pacl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL); >> >> >> > >> >> >> > What's the point? >> >> >> >> >> >> That's how the protocol is specified. >> >> > >> >> > Yep, even if we could make that change to nfsd it wouldn't help the >> >> > client with the large number of other servers that are out there >> >> > (including older knfsd's). >> >> > >> >> > --b. >> >> > >> >> >> (I'm not saying that that's very helpful.) >> >> >> >> >> >> Andreas >> >> >> >> Hi everyone. >> >> I have a customer facing this problem, and so stumbled onto the email >> >> thread. >> >> Unfortunately it didn't resolve anything. Maybe I can help kick things >> >> along??? >> >> >> >> The core problem here is that NFSv4 and ext4 use different and largely >> >> incompatible ACL implementations. There is no way to accurately >> >> translate from one to the other in general (common specific examples >> >> can be converted). >> >> >> >> This means that either: >> >>1/ overlayfs cannot use ext4 for upper and NFS for lower (or vice >> >> versa) or >> >>2/ overlayfs need to accept that sometimes it cannot copy ACLs, and >> >> that is OK. >> >> >> >> Silently not copying the ACLs is probably not a good idea as it might >> >> result in inappropriate permissions being given away. >> > >> > For example? permissions given away to do what? >> > Note that ovl_permission() only check permissions of *mounter* >> > to read the lower NFS file and ovl_open()/ovl_read_iter() access >> > the lower file with *mounter* credentials. >> > >> > I might be wrong, but seems to me that once admin mounted >> > overlayfs with lower NFS, NFS ACLs are not being enforced at all >> > even before copy up. >> >> I guess it is just as well that copy-up fails then - if the lower-level >> permission check is being ignored. >> >> > >> >> So if the >> >> sysadmin wants this (and some clearly do), they need a way to >> >> explicitly say "I accept the risk". If only standard Unix permissions >> >> are used, there is no risk, so this seems reasonable. >> >> >> >> So I would like to propose a new option for overlayfs >> >> nocopyupacl: when overlayfs is copying a file (or directory etc) >> >>
linux-next: build failure after merge of the clk tree
Hi all,
After merging the clk tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
arch/arm/mach-omap2/omap_hwmod.c: In function '_get_clkdm':
arch/arm/mach-omap2/omap_hwmod.c:669:35: error: 'CLK_IS_BASIC' undeclared
(first use in this function); did you mean 'CLOCKS_MASK'?
if (__clk_get_flags(oh->_clk) & CLK_IS_BASIC)
^~~~
CLOCKS_MASK
arch/arm/mach-omap2/omap_hwmod.c:669:35: note: each undeclared identifier is
reported only once for each function it appears in
Caused by commit
7c36ec8a90a8 ("clk: Remove CLK_IS_BASIC clk flag")
I have used the clk tree from next-20190502 for today. (The above commit
does not revert cleanly.)
--
Cheers,
Stephen Rothwell
pgpxaBeDvQuVg.pgp
Description: OpenPGP digital signature
Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image
On Thu, 2 May 2019, Matthew Garrett wrote: > On Thu, May 2, 2019 at 2:07 PM James Morris wrote: > > One possible direction is to (as previously mentioned) assign IDs to each > > callsite and be able to check this ID against a simple policy array > > (allow/deny). The default policy choices could be reduced to 'all' or > > 'none' during kconfig, and allow a custom policy to be loaded later if > > desired. > > Ok. My primary concern around this is that it's very difficult to use > correctly in anything other than the "all" or "none" modes. If a new > kernel feature is added with integrated lockdown support, if an admin > is simply setting the flags of things they wish to block then this > will be left enabled - and may violate the admin's expectations around > integrity. On the other hand, if an admin is simply setting the flags > of things they wish to permit, then adding lockdown support to an > existing kernel feature may result in that feature suddenly being > disabled, which may also violate the admin's expectations around the > flags providing a stable set of behaviour. Understood. Most uses will likely be either a distro or an embedded system, who I'm assuming would provide a useful policy by default, and perhaps a high-level abstraction for modification. > Given that, would you prefer such a policy expression to look like? Perhaps a write-once policy, injected from userspace during early boot? The policy could be simply a list of: lockdown_feature true|false > > > Within the policy check hook, we could add a new LSM hook, which would > > allow an LSM to restrictively override the lockdown policy with its own > > Ok, that makes sense. If we take this approach, does there need to be > a separate policy mechanism at all? Users who want fine-grained > control would be able to set the behaviour to "None" and then use > their choice of LSM to express more fine-grained control. Right, and there could be a stackable LSM which just does fine-grained policy (per above). > > > This doesn't really address the completeness / maintenance issue (i.e. "do > > we have everything covered and how do we ensure this on an ongoing > > basis?", and "what will this new lockdown feature break?"), although it > > should make it easier to add new lockdown callsites as they don't have to > > be enabled by the user. > > I can start on this. Cool! -- James Morris
Re: [RFC] Disable lockref on arm64
On Thu, May 02, 2019 at 09:12:18AM -0700, Linus Torvalds wrote: > On Thu, May 2, 2019 at 1:27 AM Jan Glauber wrote: > > > > I'll see how x86 runs the same testcase, I thought that playing > > cacheline ping-pong is not the optimal use case for any CPU. > > Oh, ping-pong is always bad. > > But from past experience, x86 tends to be able to always do tight a > cmpxchg loop without failing more than a once or twice, which is all > you need for things like this. I don't really see the point your are making about hardware. If you look at the test case, you have about 64 cores doing CAS to the same location. At any point one of them will succeed and the other 63 will fail - and in our case since cpu_relax is a nop, they sit in a tight loop mostly failing. And further due to the nature of the test case, the successful thread will come back almost immediately with another CAS. > And it's "easy" to do in hardware on a CPU: all you need to do is > guarantee that when you have a cmpxchg loop, the cacheline is sticky > enough that it stays around at the local CPU for the duration of one > loop entry (ie from one cmpxchg to the next). > > Obviously you can do that wrong too, and make cachelines *too* sticky, > and then you get fairness issues. This is certainly not the case, we are not bouncing around not making progress at all. We have all 64 cores hitting the same location in a very tight loop slowing the system down. And you will get fairness issues anyway about which of the failing cores succeeds next. The testcase does not hang indefinitely, it eventually completes. The scaling loss is, in my opinion, due to the naive lockref implementation, rather than due to a hardware limitation. Are you expecting the hardware cache coherency implementation to have the equivalent of queued locks and block potentially failing CAS? After speaking to the folks doing performance comparisons here, x86 suffers in the same test case as well, when there are enough cores. Your patch that switches to spinlock (in this case queued) works nicely in case of high contention. Is this something that will be merged to mainline? We can provide some testing results if that will help. > But it really sounds like what happens for your ThunderX2 case, the > different CPU's steal each others cachelines so quickly that even when > you get the cacheline, you don't then get to update it. > > Does ThunderX2 do LSE atomics? Are the acquire/release versions really > slow, perhaps, and more or less serializing (maybe it does the > "release" logic even when the store _fails_?), so that doing two > back-to-back cmpxchg ends up taking the core a "long" time, so that > the cache subsystem then steals it easily in between cmpxchg's in a > loop? Does the L1 cache maybe have no way to keep a line around from > one cmpxchg to the next? ThunderX2 has LSE atomics. It has also full out-of-order execution with weak ordering for load/store, so a barrier will be slow down exection. Also to address some points on the earlier rant: ThunderX2 is a fairly beefy processor (based on Broadcom Vulcan), it compares well on per-core performance with x86 (and with A76 from what I hear even though A76 was out a few years later). There are more cores per socket due to the fact that there is no ISA baggage, and not really due to a weaker core. > This is (one example) where having a CPU and an interconnect that > works together matters. And yes, it probably needs a few generations > of hardware tuning where people see problems and fix them. The next generation ThunderX3 is in the works, and it will have even more cores, it is going to be fun :) JC
Re: [PATCH v6 00/12] mm: Sub-section memory hotplug support
On Thu, May 2, 2019 at 3:46 PM Pavel Tatashin wrote: > > Hi Dan, > > How do you test these patches? Do you have any instructions? Yes, I briefly mentioned this in the cover letter, but here is the test I am using: > > I see for example that check_hotplug_memory_range() still enforces > memory_block_size_bytes() alignment. > > Also, after removing check_hotplug_memory_range(), I tried to online > 16M aligned DAX memory, and got the following panic: Right, this functionality is currently strictly limited to the devm_memremap_pages() case where there are guarantees that the memory will never be onlined. This is due to the fact that the section size is entangled with the memblock api. That said I would have expected you to trigger the warning in subsection_check() before getting this far into the hotplug process. > > # echo online > /sys/devices/system/memory/memory7/state > [ 202.193132] WARNING: CPU: 2 PID: 351 at drivers/base/memory.c:207 > memory_block_action+0x110/0x178 > [ 202.193391] Modules linked in: > [ 202.193698] CPU: 2 PID: 351 Comm: sh Not tainted > 5.1.0-rc7_pt_devdax-00038-g865af4385544-dirty #9 > [ 202.193909] Hardware name: linux,dummy-virt (DT) > [ 202.194122] pstate: 6005 (nZCv daif -PAN -UAO) > [ 202.194243] pc : memory_block_action+0x110/0x178 > [ 202.194404] lr : memory_block_action+0x90/0x178 > [ 202.194506] sp : 16763ca0 > [ 202.194592] x29: 16763ca0 x28: 80016fd29b80 > [ 202.194724] x27: x26: > [ 202.194838] x25: 15546000 x24: 001c > [ 202.194949] x23: x22: 0004 > [ 202.195058] x21: 001c x20: 0008 > [ 202.195168] x19: 0007 x18: > [ 202.195281] x17: x16: > [ 202.195393] x15: x14: > [ 202.195505] x13: x12: > [ 202.195614] x11: x10: > [ 202.195744] x9 : x8 : 00018000 > [ 202.195858] x7 : 0018 x6 : 15541930 > [ 202.195966] x5 : 15541930 x4 : 0001 > [ 202.196074] x3 : 0001 x2 : > [ 202.196185] x1 : 0070 x0 : > [ 202.196366] Call trace: > [ 202.196455] memory_block_action+0x110/0x178 > [ 202.196589] memory_subsys_online+0x3c/0x80 > [ 202.196681] device_online+0x6c/0x90 > [ 202.196761] state_store+0x84/0x100 > [ 202.196841] dev_attr_store+0x18/0x28 > [ 202.196927] sysfs_kf_write+0x40/0x58 > [ 202.197010] kernfs_fop_write+0xcc/0x1d8 > [ 202.197099] __vfs_write+0x18/0x40 > [ 202.197187] vfs_write+0xa4/0x1b0 > [ 202.197295] ksys_write+0x64/0xd8 > [ 202.197430] __arm64_sys_write+0x18/0x20 > [ 202.197521] el0_svc_common.constprop.0+0x7c/0xe8 > [ 202.197621] el0_svc_handler+0x28/0x78 > [ 202.197706] el0_svc+0x8/0xc > [ 202.197828] ---[ end trace 57719823dda6d21e ]--- > > Thank you, > Pasha
Re: [PATCH] OVL: add honoracl=off mount option.
On Thu, May 02 2019, Amir Goldstein wrote: > On Thu, May 2, 2019 at 12:35 AM NeilBrown wrote: >> >> >> If the upper and lower layers use incompatible ACL formats, it is not >> possible to copy the ACL xttr from one to the other, so overlayfs >> cannot work with them. >> This happens particularly with NFSv4 which uses system.nfs4_acl, and >> ext4 which uses system.posix_acl_access. >> >> If all ACLs actually make to Unix permissions, then there is no need >> to copy up the ACLs, but overlayfs cannot determine this. >> >> So allow the sysadmin it assert that ACLs are not needed with a mount >> option >> honoracl=off >> This causes the ACLs to not be copied, so filesystems with different >> ACL formats can be overlaid together. >> >> Signed-off-by: NeilBrown >> --- >> Documentation/filesystems/overlayfs.txt | 24 >> fs/overlayfs/copy_up.c | 9 +++-- >> fs/overlayfs/dir.c | 2 +- >> fs/overlayfs/overlayfs.h| 2 +- >> fs/overlayfs/ovl_entry.h| 1 + >> fs/overlayfs/super.c| 15 +++ >> 6 files changed, 49 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/filesystems/overlayfs.txt >> b/Documentation/filesystems/overlayfs.txt >> index eef7d9d259e8..7ad675940c93 100644 >> --- a/Documentation/filesystems/overlayfs.txt >> +++ b/Documentation/filesystems/overlayfs.txt >> @@ -245,6 +245,30 @@ filesystem - future operations on the file are barely >> noticed by the >> overlay filesystem (though an operation on the name of the file such as >> rename or unlink will of course be noticed and handled). >> >> +ACL copy-up >> +--- >> + >> +When a file that only exists on the lower layer is modified it needs >> +to be copied up to the upper layer. This means copying the metadata >> +and (usually) the data (though see "Metadata only copy up" below). >> +One part of the metadata can be problematic: the ACLs. >> + >> +Now all filesystems support ACLs, and when they do they don't all use >> +the same format. A significant conflict appears between POSIX acls >> +used on many local filesystems, and NFSv4 ACLs used with NFSv4. There >> +two formats are, in general, not inter-convertible. >> + >> +If a site only uses regular Unix permissions (Read, Write, eXecute by >> +User, Group and Other), then as these permissions are compatible with >> +all ACLs, there is no need to copy ACLs. overlayfs cannot determine >> +if this is the case itself. >> + >> +For this reason, overlayfs supports a mount option "honoracl=off" >> +which causes ACLs, any "system." extended attribute, on the lower >> +layer to be ignored and, particularly, not copied to the upper later. >> +This allows NFSv4 to be overlaid with a local filesystem, but should >> +only be used if the only access controls used on the filesystem are >> +Unix permission bits. >> > > I don't know. On the one hand "system." is not only ACLs. Isn't it? What else goes in "system." "?? "man xattr" says: Extended system attributes Extended system attributes are used by the kernel to store system objects such as Access Control Lists. Read and write access permissions to system attributes depend on the policy implemented for each system attribute implemented by filesystems in the kernel. so it *allows* things other than ACLs, but doesn't confirm that there are any. In the kernel source, "XATTR_SYSTEM_PREFIX" is only used with POSIX acls and "system.sockprotoname" - which is socket specific and no likely to be found on a filesystem. "system. also appears in CIFS_XATTR_CIFS_ACL SMB3_XATTR_CIFS_ACL F2FS_SYSTEM_ADVISE_NAME XATTR_NAME_NFSV4_ACL SYSTEM_ORANGEFS_KEY which should all use XATTR_SYSTEM_PREFIX ... So yes, I guess they aren't (quite) all ACLs. Bother. > On the other hand, "honoracl=off" is not the same as -o noacl, > but it sure sounds the same. > > I'd be a lot more comfortable with "ignore_xattrs=system.nfs4_acl" > argument takes a comma separated list of xattr prefixes to ignore. That requires the sysadmin to know a lot more about the internals of the relevant filesystems Maybe that is a good idea, but it feels rather clunky. In each of these cases, except maybe POSIX_ACLs, it doesn't make sense to copy-up the "system." xattr unless it is the exact same filesystem type. So if given a "noacl" flag (or similar), ignoring copy-up failure for all "system." attributes is probably the right thing to do, as ACLs are the only system. attribute for which it can make any sense at all to copy them. Thanks, NeilBrown > > ovl_is_private_xattr() can be generalized to ovl_is_ignored_xattr(), > going over a blacklist of N>=1 which will also be called from > ovl_can_list(), because there is no point in listing the ACLs that > are ignored. right? > > Thanks, > Amir. signature.asc Description: PGP signature
Re: [PATCH 4.9 00/32] 4.9.173-stable review
stable-rc/linux-4.9.y boot: 104 boots: 2 failed, 99 passed with 3 offline (v4.9.172-33-gd35bcd092304) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.172-33-gd35bcd092304/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.172-33-gd35bcd092304/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.172-33-gd35bcd092304 Git Commit: d35bcd0923041bd98c18947041f8929b2fb12674 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 51 unique boards, 22 SoC families, 15 builds out of 197 Boot Regressions Detected: arm: exynos_defconfig: gcc-7: exynos5250-snow: lab-collabora: new failure (last pass: v4.9.172) multi_v7_defconfig: gcc-7: stih410-b2120: lab-baylibre-seattle: new failure (last pass: v4.9.172) Boot Failures Detected: arm: exynos_defconfig: gcc-7: exynos5250-snow: 1 failed lab multi_v7_defconfig: gcc-7: stih410-b2120: 1 failed lab Offline Platforms: arm: davinci_all_defconfig: gcc-7 dm365evm,legacy: 1 offline lab exynos_defconfig: gcc-7 exynos5800-peach-pi: 1 offline lab multi_v7_defconfig: gcc-7 exynos5800-peach-pi: 1 offline lab --- For more info write to
Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
On Thu, May 02 2019, Miklos Szeredi wrote: > On Thu, May 2, 2019 at 10:05 AM Andreas Gruenbacher > wrote: >> >> On Thu, 2 May 2019 at 05:57, NeilBrown wrote: >> > On Wed, May 01 2019, Amir Goldstein wrote: >> > > On Wed, May 1, 2019 at 10:03 PM NeilBrown wrote: >> > >> On Tue, Dec 06 2016, J. Bruce Fields wrote: >> > >> > On Tue, Dec 06, 2016 at 02:18:31PM +0100, Andreas Gruenbacher wrote: >> > >> >> On Tue, Dec 6, 2016 at 11:08 AM, Miklos Szeredi >> > >> >> wrote: >> > >> >> > On Tue, Dec 6, 2016 at 12:24 AM, Andreas Grünbacher >> > >> >> > wrote: >> > >> >> >> 2016-12-06 0:19 GMT+01:00 Andreas Grünbacher >> > >> >> >> : >> > >> >> > >> > >> >> >>> It's not hard to come up with a heuristic that determines if a >> > >> >> >>> system.nfs4_acl value is equivalent to a file mode, and to >> > >> >> >>> ignore the >> > >> >> >>> attribute in that case. (The file mode is transmitted in its own >> > >> >> >>> attribute already, so actually converting .) That way, overlayfs >> > >> >> >>> could >> > >> >> >>> still fail copying up files that have an actual ACL. It's still >> > >> >> >>> an >> > >> >> >>> ugly hack ... >> > >> >> >> >> > >> >> >> Actually, that kind of heuristic would make sense in the NFS >> > >> >> >> client >> > >> >> >> which could then hide the "system.nfs4_acl" attribute. >> >> I still think the nfs client could make this problem mostly go away by >> not exposing "system.nfs4_acl" xattrs when the acl is equivalent to >> the file mode. The richacl patches contain a workable abgorithm for >> that. The problem would remain for files that have an actual NFS4 ACL, >> which just cannot be mapped to a file mode or to POSIX ACLs in the >> general case, as well as for files that have a POSIX ACL. Mapping NFS4 >> ACL that used to be a POSIX ACL back to POSIX ACLs could be achieved >> in many cases as well, but the code would be quite messy. A better way >> seems to be to using a filesystem that doesn't support POSIX ACLs in >> the first place. Unfortunately, xfs doesn't allow turning off POSIX >> ACLs, for example. > > How about mounting NFSv4 with noacl? That should fix this issue, right? No. "noacl" only affect NFSv3 (and maybe v2) and it disables use of the NFSACL side-protocol. "noacl" has no effect on an NFSv4 mount. NeilBrown signature.asc Description: PGP signature
Re: [PATCH v4 0/1] Add support for IPMB driver
On Thu, May 02, 2019 at 09:14:46PM +, Vadim Pasternak wrote: > [...] > > > > > > >>Better, if you can avoid cast. > > > >>Would compiler warn if you use for example rol16(client->addr, 1) & > > GENMASK(7, 0); or something like it? > > > I thought it wouldn't be too much of an issue to use typecast here since > > > other > > existing ipmi drivers use typecasting: bt-bmc.c, kcs_bmc_aspeed.c, > > kcs_bmc_npcm7xx.c all use (u8) typecasting. > > > But if you really think it is worth it, I could do that. > > > I just think it is not as straight forward to read this code as using a > > > simple > > typecast. Some might wonder why a GENMASK is needed in this case. > > > > > Hi Asmaa, > > I will not insist in case it's OK with maintainers. > > [...] I'm mostly against casts unless they are necessary, as they tend to clutter up the code. But I don't feel that strongly about it. I'm not sure how other maintainers feel. -corey
[PATCH v2 1/2] platform/chrome: wilco_ec: Remove 256 byte transfers
The 0xF6 command, intended to send and receive 256 byte payloads to
and from the EC, is not needed. The 0xF5 command for 32 byte
payloads is sufficient. This patch removes support for the 0xF6
command and 256 byte payloads.
Signed-off-by: Nick Crews
---
Documentation/ABI/testing/debugfs-wilco-ec | 16 +++-
drivers/platform/chrome/wilco_ec/core.c| 4 +---
drivers/platform/chrome/wilco_ec/debugfs.c | 10 ++
drivers/platform/chrome/wilco_ec/mailbox.c | 19 ---
include/linux/platform_data/wilco-ec.h | 9 ++---
5 files changed, 16 insertions(+), 42 deletions(-)
diff --git a/Documentation/ABI/testing/debugfs-wilco-ec
b/Documentation/ABI/testing/debugfs-wilco-ec
index 73a5a66ddca6..9d8d9d2def5b 100644
--- a/Documentation/ABI/testing/debugfs-wilco-ec
+++ b/Documentation/ABI/testing/debugfs-wilco-ec
@@ -23,11 +23,9 @@ Description:
For writing, bytes 0-1 indicate the message type, one of enum
wilco_ec_msg_type. Byte 2+ consist of the data passed in the
- request, starting at MBOX[0]
-
- At least three bytes are required for writing, two for the type
- and at least a single byte of data. Only the first
- EC_MAILBOX_DATA_SIZE bytes of MBOX will be used.
+ request, starting at MBOX[0]. At least three bytes are required
+ for writing, two for the type and at least a single byte of
+ data.
Example:
// Request EC info type 3 (EC firmware build date)
@@ -40,7 +38,7 @@ Description:
$ cat /sys/kernel/debug/wilco_ec/raw
00 00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00
..12/21/18.8...
- Note that the first 32 bytes of the received MBOX[] will be
- printed, even if some of the data is junk. It is up to you to
- know how many of the first bytes of data are the actual
- response.
+ Note that the first 16 bytes of the received MBOX[] will be
+ printed, even if some of the data is junk, and skipping bytes
+ 17 to 32. It is up to you to know how many of the first bytes of
+ data are the actual response.
diff --git a/drivers/platform/chrome/wilco_ec/core.c
b/drivers/platform/chrome/wilco_ec/core.c
index 05e1e2be1c91..d060d3aa5bae 100644
--- a/drivers/platform/chrome/wilco_ec/core.c
+++ b/drivers/platform/chrome/wilco_ec/core.c
@@ -52,9 +52,7 @@ static int wilco_ec_probe(struct platform_device *pdev)
ec->dev = dev;
mutex_init(>mailbox_lock);
- /* Largest data buffer size requirement is extended data response */
- ec->data_size = sizeof(struct wilco_ec_response) +
- EC_MAILBOX_DATA_SIZE_EXTENDED;
+ ec->data_size = sizeof(struct wilco_ec_response) + EC_MAILBOX_DATA_SIZE;
ec->data_buffer = devm_kzalloc(dev, ec->data_size, GFP_KERNEL);
if (!ec->data_buffer)
return -ENOMEM;
diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c
b/drivers/platform/chrome/wilco_ec/debugfs.c
index f163476d080d..281ec595e8e0 100644
--- a/drivers/platform/chrome/wilco_ec/debugfs.c
+++ b/drivers/platform/chrome/wilco_ec/debugfs.c
@@ -17,13 +17,13 @@
#define DRV_NAME "wilco-ec-debugfs"
/* The 256 raw bytes will take up more space when represented as a hex string
*/
-#define FORMATTED_BUFFER_SIZE (EC_MAILBOX_DATA_SIZE_EXTENDED * 4)
+#define FORMATTED_BUFFER_SIZE (EC_MAILBOX_DATA_SIZE * 4)
struct wilco_ec_debugfs {
struct wilco_ec_device *ec;
struct dentry *dir;
size_t response_size;
- u8 raw_data[EC_MAILBOX_DATA_SIZE_EXTENDED];
+ u8 raw_data[EC_MAILBOX_DATA_SIZE];
u8 formatted_data[FORMATTED_BUFFER_SIZE];
};
static struct wilco_ec_debugfs *debug_info;
@@ -124,12 +124,6 @@ static ssize_t raw_write(struct file *file, const char
__user *user_buf,
msg.response_data = debug_info->raw_data;
msg.response_size = EC_MAILBOX_DATA_SIZE;
- /* Telemetry commands use extended response data */
- if (msg.type == WILCO_EC_MSG_TELEMETRY_LONG) {
- msg.flags |= WILCO_EC_FLAG_EXTENDED_DATA;
- msg.response_size = EC_MAILBOX_DATA_SIZE_EXTENDED;
- }
-
ret = wilco_ec_mailbox(debug_info->ec, );
if (ret < 0)
return ret;
diff --git a/drivers/platform/chrome/wilco_ec/mailbox.c
b/drivers/platform/chrome/wilco_ec/mailbox.c
index 7fb58b487963..c9c6c3194d12 100644
--- a/drivers/platform/chrome/wilco_ec/mailbox.c
+++ b/drivers/platform/chrome/wilco_ec/mailbox.c
@@ -119,7 +119,6 @@ static int wilco_ec_transfer(struct wilco_ec_device *ec,
struct wilco_ec_response *rs;
u8 checksum;
u8 flag;
- size_t size;
/* Write request header, then data */
cros_ec_lpc_io_bytes_mec(MEC_IO_WRITE, 0, sizeof(*rq), (u8 *)rq);
@@ -148,21 +147,11 @@ static int
[PATCH 4/5] ARM: dts: rockchip: Add unwedge pinctrl entries for dw_hdmi on rk3288
This adds the "unwedge" pinctrl entries introduced by a recent dw_hdmi
change that can unwedge the dw_hdmi i2c bus in some cases. It's
expected that any boards using this would add:
pinctrl-names = "default", "unwedge";
pinctrl-0 = <_ddc>;
pinctrl-1 = <_ddc_unwedge>;
Note that this isn't added by default because some boards may choose
to mux i2c5 for their DDC bus (if that is more tested for them).
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/rk3288.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 74c9517c4f92..eebc04fa1e4d 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1545,6 +1545,15 @@
rockchip,pins = <7 RK_PC3 2 _pull_none>,
<7 RK_PC4 2 _pull_none>;
};
+
+ hdmi_ddc_unwedge: hdmi-ddc-unwedge {
+ rockchip,pins = <7 RK_PC3 RK_FUNC_GPIO
_output_low>,
+ <7 RK_PC4 2 _pull_none>;
+ };
+ };
+
+ pcfg_output_low: pcfg-output-low {
+ output-low;
};
pcfg_pull_up: pcfg-pull-up {
--
2.21.0.1020.gf2820cf01a-goog
[PATCH v2 2/2] platform/chrome: wilco_ec: Add telemetry char device interface
The Wilco Embedded Controller is able to send telemetry data
which is useful for enterprise applications. A daemon running on
the OS sends a command to the EC via a write() to a char device,
and can read the response with a read(). The write() request is
verified by the driver to ensure that it is performing only one
of the whitelisted commands, and that no extraneous data is
being transmitted to the EC. The response is passed directly
back to the reader with no modification.
The character device will appear as /dev/wilco_telemN, where N
is some small non-negative integer, starting with 0. Only one
process may have the file descriptor open at a time. The calling
userspace program needs to keep the device file descriptor open
between the calls to write() and read() in order to preserve the
response. 32 bytes of data are expected for arguments, and 32
bytes will be available for reading.
For testing purposes, try requesting the EC's firmware build
date, by sending the WILCO_EC_CMD_GET_VERSION command with
argument index=3. i.e. write [0x38, 0x00, 0x03, ...(29 more 0s)]
to the device node. An ASCII string of the build date is
returned.
Signed-off-by: Nick Crews
---
v2 changes:
- Add verification of userspace requests, so that only
whitelisted commands and args can get sent to the EC
- Use EC firmware build date request as example/test
- Pass the wilco_ec_device to the child driver better,
instead of the child driver needing to access the parent
devices' data.
drivers/platform/chrome/wilco_ec/Kconfig | 7 +
drivers/platform/chrome/wilco_ec/Makefile| 2 +
drivers/platform/chrome/wilco_ec/core.c | 13 +
drivers/platform/chrome/wilco_ec/debugfs.c | 2 +-
drivers/platform/chrome/wilco_ec/telemetry.c | 433 +++
include/linux/platform_data/wilco-ec.h | 2 +
6 files changed, 458 insertions(+), 1 deletion(-)
create mode 100644 drivers/platform/chrome/wilco_ec/telemetry.c
diff --git a/drivers/platform/chrome/wilco_ec/Kconfig
b/drivers/platform/chrome/wilco_ec/Kconfig
index e09e4cebe9b4..2fc03aa624cf 100644
--- a/drivers/platform/chrome/wilco_ec/Kconfig
+++ b/drivers/platform/chrome/wilco_ec/Kconfig
@@ -18,3 +18,10 @@ config WILCO_EC_DEBUGFS
manipulation and allow for testing arbitrary commands. This
interface is intended for debug only and will not be present
on production devices.
+
+config WILCO_EC_TELEMETRY
+ tristate "Enable querying telemetry data from EC"
+ depends on WILCO_EC
+ help
+ If you say Y here, you get support to query EC telemetry data from
+ /dev/wilco_telem0 using write() and then read().
diff --git a/drivers/platform/chrome/wilco_ec/Makefile
b/drivers/platform/chrome/wilco_ec/Makefile
index 063e7fb4ea17..b4aa6d26a3df 100644
--- a/drivers/platform/chrome/wilco_ec/Makefile
+++ b/drivers/platform/chrome/wilco_ec/Makefile
@@ -4,3 +4,5 @@ wilco_ec-objs := core.o mailbox.o
obj-$(CONFIG_WILCO_EC) += wilco_ec.o
wilco_ec_debugfs-objs := debugfs.o
obj-$(CONFIG_WILCO_EC_DEBUGFS) += wilco_ec_debugfs.o
+wilco_ec_telem-objs:= telemetry.o
+obj-$(CONFIG_WILCO_EC_TELEMETRY) += wilco_ec_telem.o
diff --git a/drivers/platform/chrome/wilco_ec/core.c
b/drivers/platform/chrome/wilco_ec/core.c
index d060d3aa5bae..4cb05d80e5af 100644
--- a/drivers/platform/chrome/wilco_ec/core.c
+++ b/drivers/platform/chrome/wilco_ec/core.c
@@ -87,8 +87,20 @@ static int wilco_ec_probe(struct platform_device *pdev)
goto unregister_debugfs;
}
+ /* Register child device that will be found by the telemetry driver. */
+ ec->telem_pdev = platform_device_register_data(dev, "wilco_telem",
+ PLATFORM_DEVID_AUTO,
+ ec, sizeof(*ec));
+ if (IS_ERR(ec->telem_pdev)) {
+ dev_err(dev, "Failed to create telemetry platform device\n");
+ ret = PTR_ERR(ec->telem_pdev);
+ goto unregister_rtc;
+ }
+
return 0;
+unregister_rtc:
+ platform_device_unregister(ec->rtc_pdev);
unregister_debugfs:
if (ec->debugfs_pdev)
platform_device_unregister(ec->debugfs_pdev);
@@ -100,6 +112,7 @@ static int wilco_ec_remove(struct platform_device *pdev)
{
struct wilco_ec_device *ec = platform_get_drvdata(pdev);
+ platform_device_unregister(ec->telem_pdev);
platform_device_unregister(ec->rtc_pdev);
if (ec->debugfs_pdev)
platform_device_unregister(ec->debugfs_pdev);
diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c
b/drivers/platform/chrome/wilco_ec/debugfs.c
index 281ec595e8e0..8d65a1e2f1a3 100644
--- a/drivers/platform/chrome/wilco_ec/debugfs.c
+++ b/drivers/platform/chrome/wilco_ec/debugfs.c
@@ -16,7 +16,7 @@
#define DRV_NAME "wilco-ec-debugfs"
-/* The 256 raw bytes
[PATCH 5/5] ARM: dts: rockchip: Add HDMI i2c unwedging for rk3288-veyron
Veyron uses the builtin i2c controller that's part of dw-hdmi. Hook
up the unwedging feature.
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
b/arch/arm/boot/dts/rk3288-veyron.dtsi
index e1bee663d2c5..340b276b6333 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -163,8 +163,9 @@
};
{
- pinctrl-names = "default";
+ pinctrl-names = "default", "unwedge";
pinctrl-0 = <_ddc>;
+ pinctrl-1 = <_ddc_unwedge>;
status = "okay";
};
--
2.21.0.1020.gf2820cf01a-goog
[PATCH 3/5] ARM: dts: rockchip: Switch to builtin HDMI DDC bus on rk3288-veyron
Downstream Chrome OS kernels use the builtin DDC bus from dw_hdmi on
veyron. This is the only way to get them to negotiate HDCP.
Although HDCP isn't currently all supported upstream, it still seems
like it makes sense to use dw_hdmi's builtin I2C. Maybe eventually we
can get HDCP negotiation working.
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 1252522392c7..e1bee663d2c5 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -163,7 +163,8 @@
};
{
- ddc-i2c-bus = <>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_ddc>;
status = "okay";
};
@@ -334,14 +335,6 @@
i2c-scl-rising-time-ns = <300>; /* 225ns measured */
};
- {
- status = "okay";
-
- clock-frequency = <10>;
- i2c-scl-falling-time-ns = <300>;
- i2c-scl-rising-time-ns = <1000>;
-};
-
_domains {
status = "okay";
--
2.21.0.1020.gf2820cf01a-goog
Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions
On Thu, 2 May 2019 22:21:46 +0200 Peter Zijlstra wrote: > On Thu, May 02, 2019 at 11:43:37AM -0700, Linus Torvalds wrote: > > What would it look like with the "int3-from-kernel is special" > > modification? > > Something like so; it boots; but I could've made some horrible mistake > (again). > > --- > diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S > index 7b23431be5cb..4de51cff5b8a 100644 > --- a/arch/x86/entry/entry_32.S > +++ b/arch/x86/entry/entry_32.S Oh, and so close! I was running this on my i386 tests and for test 8 of 9 (passed 1-7) I hit this: Testing all events: OK Testing ftrace filter: OK trace_kprobe: Testing kprobe tracing: BUG: unable to handle kernel paging request at 10ec839c #PF error: [INSTR] *pdpt = *pde = Oops: 0010 [#1] SMP PTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc3-test+ #1 Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014 EIP: 0x10ec839c Code: Bad RIP value. EAX: 54e24bbc EBX: ECX: 0003 EDX: 0002 ESI: ebcae400 EDI: c1513a88 EBP: ee641f30 ESP: c0439a07 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210202 CR0: 80050033 CR2: 10ec8392 CR3: 0167e000 CR4: 001406f0 Call Trace: Modules linked in: CR2: 10ec839c ---[ end trace 8aa996061578b437 ]--- EIP: 0x10ec839c Code: Bad RIP value. EAX: 54e24bbc EBX: ECX: 0003 EDX: 0002 ESI: ebcae400 EDI: c1513a88 EBP: ee641f30 ESP: c16834bc DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210202 CR0: 80050033 CR2: 10ec8392 CR3: 0167e000 CR4: 001406f0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 Kernel Offset: disabled ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 ]--- [ cut here ] sched: Unexpected reschedule of offline CPU#3! WARNING: CPU: 1 PID: 1 at arch/x86/kernel/smp.c:128 native_smp_send_reschedule+0x1c/0x37 Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Tainted: G D 5.1.0-rc3-test+ #1 Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014 EIP: native_smp_send_reschedule+0x1c/0x37 Code: 4a 18 ba fb 00 00 00 e8 71 d6 9c 00 5d c3 55 89 e5 e8 37 6f 00 00 0f a3 05 e0 20 44 c1 72 11 50 68 d2 75 15 c1 e8 c7 a4 01 00 <0f> 0b 58 5a eb 13 8b 15 c0 36 28 c1 8b 4a 18 ba fd 00 00 00 e8 3a EAX: 002e EBX: 0003 ECX: c049977e EDX: ee638000 ESI: 0003 EDI: 0003 EBP: ee641e04 ESP: ee641dfc DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210092 CR0: 80050033 CR2: 10ec8392 CR3: 0167e000 CR4: 001406f0 Call Trace: kick_ilb+0x77/0x7c trigger_load_balance+0x279/0x280 ? __pick_first_entity+0x18/0x18 scheduler_tick+0x90/0xa9 ? __pick_first_entity+0x18/0x18 update_process_times+0x3f/0x4a tick_sched_handle+0x4c/0x5a tick_sched_timer+0x3b/0x79 ? tick_sched_do_timer+0x44/0x44 __hrtimer_run_queues+0x180/0x26a ? tick_sched_do_timer+0x44/0x44 hrtimer_interrupt+0xa6/0x18e ? rcu_irq_enter+0x60/0x7e smp_apic_timer_interrupt+0xdf/0x179 apic_timer_interrupt+0xda/0xe0 EIP: panic+0x208/0x24a Code: 83 c3 64 eb ad 83 3d a8 d1 68 c1 00 74 05 e8 01 bf 01 00 68 e0 d1 68 c1 68 cc e6 15 c1 e8 bd e7 04 00 e8 02 ff 0a 00 fb 31 db <58> 5a e8 c5 a9 09 00 39 fb 7c 18 83 f6 01 8b 15 a0 d1 68 c1 89 f0 EAX: c044c764 EBX: ECX: c049977e EDX: 318e4000 ESI: EDI: EBP: ee641f6c ESP: ee641f54 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200246 ? console_unlock+0x466/0x4b8 ? panic+0x205/0x24a ? do_exit+0x4bd/0x8d1 do_exit+0x4e3/0x8d1 ? copy_oldmem_page+0x63/0x9b rewind_stack_do_exit+0x11/0x13 irq event stamp: 1400780 hardirqs last enabled at (1400779): [] trace_hardirqs_on_thunk+0xc/0x10 hardirqs last disabled at (1400780): [] trace_hardirqs_off_thunk+0xc/0x10 softirqs last enabled at (1400760): [] __do_softirq+0x2a2/0x2d2 softirqs last disabled at (1400753): [] call_on_stack+0x45/0x4b ---[ end trace 8aa996061578b438 ]--- [ cut here ] That's one of the startup tests that happens on boot up. Config attached. Good news is, it appears very reproducible. -- Steve Here's the patch I applied (both folded together): diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index d309f30cf7af..2885acd691ac 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -67,9 +67,20 @@ # define preempt_stop(clobbers)DISABLE_INTERRUPTS(clobbers); TRACE_IRQS_OFF #else # define preempt_stop(clobbers) -# define resume_kernel restore_all_kernel #endif +.macro RETINT_PREEMPT +#ifdef CONFIG_PREEMPT + DISABLE_INTERRUPTS(CLBR_ANY) + cmpl$0, PER_CPU_VAR(__preempt_count) + jnz .Lend_\@ + testl $X86_EFLAGS_IF, PT_EFLAGS(%esp) # interrupts off (exception path) ? + jz .Lend_\@ + callpreempt_schedule_irq +.Lend_\@: +#endif +.endm + .macro TRACE_IRQS_IRET #ifdef CONFIG_TRACE_IRQFLAGS testl $X86_EFLAGS_IF, PT_EFLAGS(%esp) #
