Hello,
I came along some software modules where I suggested source code adjustments.
Example:
nfs/write: Use common error handling code in nfs_lock_and_join_requests()
https://lkml.org/lkml/2017/11/7/599https://patchwork.kernel.org/patch/10047013/https://lkml.kernel.org/r/<7f072f78-eef4-6d87-d233-cee71dac5a32(a)users.sourceforge.net>
I would like to check corresponding build results then without extra
optimisation applied by the compiler.
But I got surprised by error messages for a command like the following.
elfring@Sonne:~/Projekte/Linux/next-patched> my_cc=/usr/bin/gcc-7 && LANG=C make -j4 CC="${my_cc}" HOSTCC="${my_cc}" EXTRA_CFLAGS='-O0' allmodconfig fs/nfs/write.o
…
In file included from ./include/linux/compiler.h:58:0,
from ./include/uapi/linux/stddef.h:1,
from ./include/linux/stddef.h:4,
from ./include/uapi/linux/posix_types.h:4,
from ./include/uapi/linux/types.h:13,
from ./include/linux/types.h:5,
from fs/nfs/write.c:9:
./arch/x86/include/asm/jump_label.h: In function ‘trace_nfs_writeback_page_enter’:
./include/linux/compiler-gcc.h:275:38: warning: asm operand 0 probably doesn’t match constraints
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
…
How do you think about to improve this software situation anyhow?
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Perf tool bpf selftests revealed a broken uapi for s390 and arm64.
With the BPF_PROG_TYPE_PERF_EVENT program type the bpf_perf_event
structure exports the pt_regs structure for all architectures.
This fails for s390 and arm64 because pt_regs are not part of the
user api and kept in-kernel only. To mitigate the broken uapi,
introduce a wrapper that exports pt_regs in an asm-generic way.
For arm64, export the exising user_pt_regs structure. For s390,
introduce a user_pt_regs structure that exports the beginning of
pt_regs.
Note that user_pt_regs must export from the beginning of pt_regs
as BPF_PROG_TYPE_PERF_EVENT program type is not the only type for
running BPF programs.
Some more background:
For the bpf_perf_event, there is a uapi definition that is
passed to the BPF program. For other "probe" points like
trace points, kprobes, and uprobes, there is no uapi and the
BPF program is always passed pt_regs (which is OK as the BPF
program runs in the kernel context). The perf tool can attach
BPF programs to all of these "probe" points and, optionally,
can create a BPF prologue to access particular arguments
(passed as registers). For this, it uses DWARF/CFI
information to obtain the register and calls a perf-arch
backend function, regs_query_register_offset(). This function
returns the index into (user_)pt_regs for a particular
register. Then, perf creates a BPF prologue that accesses
this register based on the passed stucture from the "probe"
point.
Part of this series, are also updates to the testing and bpf selftest
to deal with asm-specifics. To complete the bpf support in perf, the
the regs_query_register_offset function is added for s390 to support
BPF prologue creation.
Hendrik Brueckner (5):
bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type
s390/bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program
type
arm64/bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program
type
selftests/bpf: sync kernel headers and introduce arch support in
Makefile
perf s390: add regs_query_register_offset()
arch/arm64/include/asm/perf_event.h | 2 +
arch/arm64/include/uapi/asm/bpf_perf_event.h | 9 +
arch/s390/include/asm/perf_event.h | 1 +
arch/s390/include/asm/ptrace.h | 11 +-
arch/s390/include/uapi/asm/bpf_perf_event.h | 9 +
arch/s390/include/uapi/asm/ptrace.h | 11 +
include/linux/perf_event.h | 6 +-
include/uapi/asm-generic/bpf_perf_event.h | 9 +
include/uapi/linux/bpf_perf_event.h | 5 +-
kernel/events/core.c | 2 +-
tools/arch/arm64/include/uapi/asm/bpf_perf_event.h | 9 +
tools/arch/s390/include/uapi/asm/bpf_perf_event.h | 9 +
tools/arch/s390/include/uapi/asm/ptrace.h | 471 +++++++++++++++++++++
tools/include/uapi/asm-generic/bpf_perf_event.h | 9 +
tools/include/uapi/linux/bpf_perf_event.h | 6 +-
tools/perf/arch/s390/Makefile | 1 +
tools/perf/arch/s390/util/dwarf-regs.c | 32 +-
tools/perf/check-headers.sh | 1 +
tools/testing/selftests/bpf/Makefile | 14 +-
19 files changed, 602 insertions(+), 15 deletions(-)
create mode 100644 arch/arm64/include/uapi/asm/bpf_perf_event.h
create mode 100644 arch/s390/include/uapi/asm/bpf_perf_event.h
create mode 100644 include/uapi/asm-generic/bpf_perf_event.h
create mode 100644 tools/arch/arm64/include/uapi/asm/bpf_perf_event.h
create mode 100644 tools/arch/s390/include/uapi/asm/bpf_perf_event.h
create mode 100644 tools/arch/s390/include/uapi/asm/ptrace.h
create mode 100644 tools/include/uapi/asm-generic/bpf_perf_event.h
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
I have constructed another demonstration program.
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
FILE *f = fopen("/dev/full", "a");
if (!f)
goto report_failure;
{
int const c = 'X';
if (fputc(c, f) != c)
goto report_failure;
}
return EXIT_SUCCESS;
report_failure:
perror(__func__);
return errno;
}
I got the following result.
elfring@Sonne:~/Projekte/selftests> gcc-7 putc_into_full_file1.c && ./a.out; echo $?
0
Does such a simple test example need further software development considerations?
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
We have found "no MPX support" bug while running kselftests on
SuperServer 5019S-ML - x86_64 device.
Please provide your comments to fix this bug.
LKFT: 4.4-rc 4.9-rc 4.13-rc 4.14-rc: x86: kselftest mpx-mini-test_64 -
no MPX support - failed - 3869 Aborted (core dumped) (edit)
https://bugs.linaro.org/show_bug.cgi?id=3497
NOTE:
Please add your self to Bugzilla to add comments.
Best regards
Naresh Kamboju
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
These patches are fixing a bug and improve testcase to
ensure adding 256 kprobe events for test.
The 1st patch is clearly a bug, so it should be fixed
in stable kernel too.
Thank you,
---
Masami Hiramatsu (2):
[BUGFIX] selftest: ftrace: Fix to pick text symbols for kprobes
selftest: ftrace: Fix to add 256 kprobe events correctly
.../ftrace/test.d/kprobe/multiple_kprobes.tc | 21 +++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 21, 2017 at 09:18:53AM -0500, Mathieu Desnoyers wrote:
> +int percpu_list_push(struct percpu_list *list, struct percpu_list_node *node)
> +{
> + intptr_t *targetptr, newval, expect;
> + int cpu, ret;
> +
> + /* Try fast path. */
> + cpu = rseq_cpu_start();
> + /* Load list->c[cpu].head with single-copy atomicity. */
> + expect = (intptr_t)READ_ONCE(list->c[cpu].head);
> + newval = (intptr_t)node;
> + targetptr = (intptr_t *)&list->c[cpu].head;
> + node->next = (struct percpu_list_node *)expect;
> + ret = rseq_cmpeqv_storev(targetptr, expect, newval, cpu);
> + if (likely(!ret))
> + return cpu;
> + return cpu;
> +}
> +static inline __attribute__((always_inline))
> +int rseq_cmpeqv_storev(intptr_t *v, intptr_t expect, intptr_t newv,
> + int cpu)
> +{
> + __asm__ __volatile__ goto (
> + RSEQ_ASM_DEFINE_TABLE(3, __rseq_table, 0x0, 0x0, 1f, 2f-1f, 4f)
> + RSEQ_ASM_STORE_RSEQ_CS(1, 3b, rseq_cs)
> + RSEQ_ASM_CMP_CPU_ID(cpu_id, current_cpu_id, 4f)
So the actual C part of the RSEQ is subject to an ABA, right? We can get
migrated to another CPU and back again without then failing here.
It used to be that this was caught by the sequence count, but that is
now gone.
The thing that makes it work is the compare against @v:
> + "cmpq %[v], %[expect]\n\t"
> + "jnz 5f\n\t"
That then ensures things are still as we observed them before (although
this itself is also subject to ABA).
This means all RSEQ primitives that have a C part must have a cmp-and-
form, but I suppose that was already pretty much the case anyway. I just
don't remember seeing that spelled out anywhere. Then again, I've not
yet read that manpage.
> + /* final store */
> + "movq %[newv], %[v]\n\t"
> + "2:\n\t"
> + RSEQ_ASM_DEFINE_ABORT(4, __rseq_failure, RSEQ_SIG, "", abort)
> + RSEQ_ASM_DEFINE_CMPFAIL(5, __rseq_failure, "", cmpfail)
> + : /* gcc asm goto does not allow outputs */
> + : [cpu_id]"r"(cpu),
> + [current_cpu_id]"m"(__rseq_abi.cpu_id),
> + [rseq_cs]"m"(__rseq_abi.rseq_cs),
> + [v]"m"(*v),
> + [expect]"r"(expect),
> + [newv]"r"(newv)
> + : "memory", "cc", "rax"
> + : abort, cmpfail
> + );
> + return 0;
> +abort:
> + return -1;
> +cmpfail:
> + return 1;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html