* [GIT PULL 00/14] perf/core improvements and fixes
From: Arnaldo Carvalho de Melo @ 2018-03-19 19:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, linux-perf-users, Arnaldo Carvalho de Melo,
Adrian Hunter, Alexander Shishkin, Andi Kleen, Colin King,
David Ahern, Jin Yao, Jiri Olsa, Josh Poimboeuf, Kan Liang,
kernel-janitors, Laura Abbott, linux-kselftest, linuxppc-dev,
linux-trace-users, Masami Hiramatsu, Namhyung Kim, Peter Zijlstra,
Ravi Bangoria, Sergey Senozhatsky, Shuah Khan, Stephane Eranian,
Steven Rostedt, Sukadev Bhattiprolu, Tom Zanussi, Wang Nan,
Willy Tarreau, Yisheng Xie, Arnaldo Carvalho de Melo
Hi Ingo,
Please consider pulling, this has those 31 patches that were
blocked due to some problems (author not being the fist S-o-B, build
broken on ppc), those issues should all be fixed and then we have 14
patches more, described in the signed tag.
Regards,
- Arnaldo
Test results at the end of this message, as usual.
The following changes since commit 10f354a36f9a9aa1b8bffe0abc1cd43822a85bcd:
perf test: Fix exit code for record+probe_libc_inet_pton.sh (2018-03-16 13:56:31 -0300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.17-20180319
for you to fetch changes up to 1cd618838b9703eabe4a75badf433382b12f6bef:
perf tests bp_account: Fix build with clang-6 (2018-03-19 13:51:54 -0300)
----------------------------------------------------------------
perf/core improvements and fixes:
- Fixes for problems experienced with new gcc 8 warnings, that treated
as errors, broke the build, related to snprintf and casting issues.
(Arnaldo Carvalho de Melo, Jiri Olsa, Josh Poinboeuf)
- Fix build of new breakpoint 'perf test' entry with clang < 6, noticed
on fedora 25, 26 and 27 (Arnaldo Carvalho de Melo)
- Workaround problem with symbol resolution in 'perf annotate', using
the symbol name already present in the objdump output (Arnaldo Carvalho de Melo)
- Document 'perf top --ignore-vmlinux' (Arnaldo Carvalho de Melo)
- Fix out of bounds access on array fd when cnt is 100 in one of the
'perf test' entries, detected using 'cpptest' (Colin Ian King)
- Add support for the forced leader feature, i.e. 'perf report --group'
for a group of events not really grouped when scheduled (without using
{} to enclose the list of events in the command line) in pipe mode,
e.g.:
$ perf record -e cycles,instructions -o - kill | perf report --group -i -
- Use right type to access array elements in 'perf probe' (Masami Hiramatsu)
- Update POWER9 vendor events (those described in JSON format) (Sukadev Bhattiprolu)
- Discard head in overwrite_rb_find_range() (Yisheng Xie)
- Avoid setting 'quiet' to 'true' unnecessarily (Yisheng Xie)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
----------------------------------------------------------------
Arnaldo Carvalho de Melo (4):
perf annotate: Use asprintf when formatting objdump command line
perf top: Document --ignore-vmlinux
perf annotate: Use ops->target.name when available for unresolved call targets
perf tests bp_account: Fix build with clang-6
Colin Ian King (1):
perf tests: Fix out of bounds access on array fd when cnt is 100
Jiri Olsa (4):
perf record: Synthesize features before events in pipe mode
perf report: Support forced leader feature in pipe mode
perf tools: Fix snprint warnings for gcc 8
perf tools: Fix python extension build for gcc 8
Josh Poimboeuf (1):
objtool, perf: Fix GCC 8 -Wrestrict error
Masami Hiramatsu (1):
perf probe: Use right type to access array elements
Sukadev Bhattiprolu (1):
perf vendor events: Update POWER9 events
Yisheng Xie (2):
perf mmap: Discard head in overwrite_rb_find_range()
perf debug: Avoid setting 'quiet' to 'true' unnecessarily
tools/lib/str_error_r.c | 2 +-
tools/perf/Documentation/perf-top.txt | 3 +
tools/perf/builtin-record.c | 18 +-
tools/perf/builtin-report.c | 57 +++--
tools/perf/builtin-script.c | 22 +-
.../perf/pmu-events/arch/powerpc/power9/cache.json | 25 ---
.../pmu-events/arch/powerpc/power9/frontend.json | 10 -
.../pmu-events/arch/powerpc/power9/marked.json | 5 -
.../pmu-events/arch/powerpc/power9/memory.json | 5 -
.../perf/pmu-events/arch/powerpc/power9/other.json | 241 ++++++++++++++-------
.../pmu-events/arch/powerpc/power9/pipeline.json | 50 ++---
tools/perf/pmu-events/arch/powerpc/power9/pmc.json | 5 -
.../arch/powerpc/power9/translation.json | 10 +-
tools/perf/tests/attr.c | 4 +-
tools/perf/tests/bp_account.c | 10 +-
tools/perf/tests/mem.c | 2 +-
tools/perf/tests/pmu.c | 2 +-
tools/perf/util/annotate.c | 20 +-
tools/perf/util/cgroup.c | 2 +-
tools/perf/util/debug.c | 1 -
tools/perf/util/header.c | 11 +-
tools/perf/util/mmap.c | 15 +-
tools/perf/util/parse-events.c | 4 +-
tools/perf/util/pmu.c | 2 +-
tools/perf/util/probe-finder.c | 13 +-
tools/perf/util/setup.py | 2 +
26 files changed, 298 insertions(+), 243 deletions(-)
Test results:
The first ones are container (docker) based builds of tools/perf with and
without libelf support. Where clang is available, it is also used to build
perf with/without libelf.
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 of command line event specifications to then intercept the
sys_perf_event syscall to check that the perf_event_attr fields are set up as
expected, among a variety of other unit tests.
Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/
with a variety of feature sets, exercising the build with an incomplete set of
features as well as with a complete one. It is planned to have it run on each
of the containers mentioned above, using some container orchestration
infrastructure. Get in contact if interested in helping having this in place.
[root@jouet ~]# time dm
1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0
2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822
3 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0
4 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0
5 alpine:edge : Ok gcc (Alpine 6.4.0) 6.4.0
6 amazonlinux:1 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
7 amazonlinux:2 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2)
8 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
9 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
10 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
11 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
12 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
13 debian:7 : Ok gcc (Debian 4.7.2-5) 4.7.2
14 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u1) 4.9.2
15 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
16 debian:experimental : Ok gcc (Debian 7.2.0-17) 7.2.1 20171205
17 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
18 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
19 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 7.2.0-11) 7.2.0
20 debian:experimental-x-mipsel : Ok mipsel-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
21 fedora:20 : Ok gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
22 fedora:21 : Ok gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
23 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
24 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
25 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
26 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
27 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
28 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)
29 fedora:27 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
30 fedora:rawhide : Ok gcc (GCC) 8.0.1 20180222 (Red Hat 8.0.1-0.16)
31 gentoo-stage3-amd64:latest : Ok gcc (Gentoo 6.4.0-r1 p1.3) 6.4.0
32 mageia:5 : Ok gcc (GCC) 4.9.2
33 mageia:6 : Ok gcc (Mageia 5.4.0-5.mga6) 5.4.0
34 opensuse:42.1 : Ok gcc (SUSE Linux) 4.8.5
35 opensuse:42.2 : Ok gcc (SUSE Linux) 4.8.5
36 opensuse:42.3 : Ok gcc (SUSE Linux) 4.8.5
37 opensuse:tumbleweed : Ok gcc (SUSE Linux) 7.3.0
38 oraclelinux:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
39 oraclelinux:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16.0.3)
40 ubuntu:12.04.5 : Ok gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
41 ubuntu:14.04.4 : Ok gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
42 ubuntu:14.04.4-x-linaro-arm64 : Ok aarch64-linux-gnu-gcc (Linaro GCC 5.4-2017.05) 5.4.1 20170404
43 ubuntu:15.04 : Ok gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
44 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609
45 ubuntu:16.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
46 ubuntu:16.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
47 ubuntu:16.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
48 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609
49 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
50 ubuntu:16.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
51 ubuntu:16.10 : Ok gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
52 ubuntu:17.04 : Ok gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
53 ubuntu:17.10 : Ok gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0
54 ubuntu:18.04 : Ok gcc (Ubuntu 7.2.0-16ubuntu1) 7.2.0
# uname -a
Linux jouet 4.16.0-rc5-00086-gdf09348f78dc #1 SMP Fri Mar 16 09:46:40 -03 2018 x86_64 x86_64 x86_64 GNU/Linux
# perf test
1: vmlinux symtab matches kallsyms : Ok
2: Detect openat syscall event : Ok
3: Detect openat syscall event on all cpus : Ok
4: Read samples using the mmap interface : Ok
5: Test data source output : Ok
6: Parse event definition strings : Ok
7: Simple expression parser : Ok
8: PERF_RECORD_* events & perf_sample fields : Ok
9: Parse perf pmu format : Ok
10: DSO data read : Ok
11: DSO data cache : Ok
12: DSO data reopen : Ok
13: Roundtrip evsel->name : Ok
14: Parse sched tracepoints fields : Ok
15: syscalls:sys_enter_openat event fields : Ok
16: Setup struct perf_event_attr : Ok
17: Match and link multiple hists : Ok
18: 'import perf' in python : Ok
19: Breakpoint overflow signal handler : Ok
20: Breakpoint overflow sampling : Ok
21: Breakpoint accounting : Skip
22: Number of exit events of a simple workload : Ok
23: Software clock events period values : Ok
24: Object code reading : Ok
25: Sample parsing : Ok
26: Use a dummy software event to keep tracking : Ok
27: Parse with no sample_id_all bit set : Ok
28: Filter hist entries : Ok
29: Lookup mmap thread : Ok
30: Share thread mg : Ok
31: Sort output of hist entries : Ok
32: Cumulate child hist entries : Ok
33: Track with sched_switch : Ok
34: Filter fds with revents mask in a fdarray : Ok
35: Add fd to a fdarray, making it autogrow : Ok
36: kmod_path__parse : Ok
37: Thread map : Ok
38: LLVM search and compile :
38.1: Basic BPF llvm compile : Ok
38.2: kbuild searching : Ok
38.3: Compile source for BPF prologue generation : Ok
38.4: Compile source for BPF relocation : Ok
39: Session topology : Ok
40: BPF filter :
40.1: Basic BPF filtering : Ok
40.2: BPF pinning : Ok
40.3: BPF prologue generation : Ok
40.4: BPF relocation checker : Ok
41: Synthesize thread map : Ok
42: Remove thread map : Ok
43: Synthesize cpu map : Ok
44: Synthesize stat config : Ok
45: Synthesize stat : Ok
46: Synthesize stat round : Ok
47: Synthesize attr update : Ok
48: Event times : Ok
49: Read backward ring buffer : Ok
50: Print cpu map : Ok
51: Probe SDT events : Ok
52: is_printable_array : Ok
53: Print bitmap : Ok
54: perf hooks : Ok
55: builtin clang support : Skip (not compiled in)
56: unit_number__scnprintf : Ok
57: mem2node : Ok
58: x86 rdpmc : Ok
59: Convert perf time to TSC : Ok
60: DWARF unwind : Ok
61: x86 instruction decoder - new instructions : Ok
62: Use vfs_getname probe to get syscall args filenames : Ok
63: Check open filename arg using perf trace + vfs_getname: Ok
64: probe libc's inet_pton & backtrace it with ping : Ok
65: Add vfs_getname probe to get syscall args filenames : Ok
#
$ make -C tools/perf build-test
make: Entering directory '/home/acme/git/perf/tools/perf'
- tarpkg: ./tests/perf-targz-src-pkg .
make_no_libbionic_O: make NO_LIBBIONIC=1
make_no_libelf_O: make NO_LIBELF=1
make_with_clangllvm_O: make LIBCLANGLLVM=1
make_install_prefix_slash_O: make install prefix=/tmp/krava/
make_no_libbpf_O: make NO_LIBBPF=1
make_no_backtrace_O: make NO_BACKTRACE=1
make_minimal_O: make NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1 NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1 NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1 NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1 NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1
make_no_slang_O: make NO_SLANG=1
make_no_libnuma_O: make NO_LIBNUMA=1
make_clean_all_O: make clean all
make_util_map_o_O: make util/map.o
make_no_demangle_O: make NO_DEMANGLE=1
make_no_auxtrace_O: make NO_AUXTRACE=1
make_pure_O: make
make_install_bin_O: make install-bin
make_install_O: make install
make_no_libdw_dwarf_unwind_O: make NO_LIBDW_DWARF_UNWIND=1
make_tags_O: make tags
make_install_prefix_O: make install prefix=/tmp/krava
make_no_ui_O: make NO_NEWT=1 NO_SLANG=1 NO_GTK2=1
make_no_libperl_O: make NO_LIBPERL=1
make_no_gtk2_O: make NO_GTK2=1
make_static_O: make LDFLAGS=-static
make_help_O: make help
make_no_newt_O: make NO_NEWT=1
make_debug_O: make DEBUG=1
make_no_libunwind_O: make NO_LIBUNWIND=1
make_with_babeltrace_O: make LIBBABELTRACE=1
make_no_libaudit_O: make NO_LIBAUDIT=1
make_perf_o_O: make perf.o
make_no_scripts_O: make NO_LIBPYTHON=1 NO_LIBPERL=1
make_util_pmu_bison_o_O: make util/pmu-bison.o
make_no_libpython_O: make NO_LIBPYTHON=1
make_doc_O: make doc
OK
make: Leaving directory '/home/acme/git/perf/tools/perf'
$
^ permalink raw reply
* Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths
From: Naveen N. Rao @ 2018-03-19 18:54 UTC (permalink / raw)
To: Steven Rostedt
Cc: Anton Blanchard, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Nicholas Piggin, Paul Mackerras, sathnaga
In-Reply-To: <20180319101344.72144f30@gandalf.local.home>
Steven Rostedt wrote:
> On Mon, 19 Mar 2018 14:43:00 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>=20
>> diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S b/arch/power=
pc/kernel/trace/ftrace_64_mprofile.S
>> index 3f3e81852422..fdf702b4df25 100644
>> --- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
>> +++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
>> @@ -60,6 +60,19 @@ _GLOBAL(ftrace_caller)
>> mfxer r10
>> mfcr r11
>> =20
>> +#ifdef CONFIG_KVM
>> + lbz r3, PACA_FTRACE_DISABLED(r13)
>> + cmpdi r3, 0
>> + beq 1f
>> + mflr r3
>> + mtctr r3
>> + REST_GPR(3, r1)
>> + addi r1, r1, SWITCH_FRAME_SIZE
>> + mtlr r0
>> + bctr
>> +1:
>> +#endif
>=20
> I wonder if we should try to move the return out of the fast path (for
> cache reasons), as most of the time the above compare will be true. That
> is:
>=20
> #ifdef CONFIG_KVM
> lbz r3, PACA_FTRACE_DISABLED(r13)
> cmpdi r3, 0
> bne no_trace
> #endif
>=20
> /* rest of ftrace_caller code */
>=20
> /* after ftrace_caller... */
> bctr /* jump after _mcount site */
>=20
> #ifdef CONFIG_KVM
> no_trace:
> mflr r3
> mtctr r3
> REST_GPR(3, r1)
> addi r1, r1, SWITCH_FRAME_SIZE
> mtlr r0
> bctr
> #endif
Thanks, I'll incorporate those changes in my next version.
- Naveen
=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths
From: Naveen N. Rao @ 2018-03-19 18:53 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Anton Blanchard, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Paul Mackerras, Steven Rostedt, sathnaga
In-Reply-To: <20180319204059.4c3a698e@roar.ozlabs.ibm.com>
Nicholas Piggin wrote:
> On Mon, 19 Mar 2018 14:43:00 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>=20
>> We have some C code that we call into from real mode where we cannot
>> take any exceptions. Though the C functions themselves are mostly safe,
>> if these functions are traced, there is a possibility that we may take
>> an exception. For instance, in certain conditions, the ftrace code uses
>> WARN(), which uses a 'trap' to do its job.
>>=20
>> For such scenarios, introduce a new field in paca 'ftrace_disabled',
>> which is checked on ftrace entry before continuing. This field can then
>> be set to a non-zero value to disable/pause ftrace, and reset to zero to
>> resume ftrace.
>>=20
>> Since KVM is the only user for this currently, we guard the
>> ftrace/mcount checks within CONFIG_KVM. This can later be removed
>> if/when there are other users.
>=20
> Why not test HSTATE_IN_GUEST then? Add ftrace_disabled if non-KVM users
> come along.
That's indeed simpler -- thanks for the suggestion!
- Naveen
=
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h
From: christophe leroy @ 2018-03-19 17:35 UTC (permalink / raw)
To: Mark Greer
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Oliver O'Halloran, linuxppc-dev, David Gibson
In-Reply-To: <20180319160216.GD9670@animalcreek.com>
Le 19/03/2018 à 17:02, Mark Greer a écrit :
> On Mon, Mar 19, 2018 at 09:53:09AM +0100, Christophe LEROY wrote:
>>
>>
>> Le 16/03/2018 à 22:54, Mark Greer a écrit :
>>> When building a uImage or zImage using ppc6xx_defconfig and some other
>>> defconfigs, the following error occurs:
>>>
>>> BOOTCC arch/powerpc/boot/fdt.o
>>> In file included from arch/powerpc/boot/fdt.c:51:0:
>>> ../arch/powerpc/boot/libfdt_env.h:10:13: error: redefinition of typedef 'uint32_t'
>>> ../arch/powerpc/boot/types.h:21:13: note: previous declaration of 'uint32_t' was here
>>> ../arch/powerpc/boot/libfdt_env.h:11:13: error: redefinition of typedef 'uint64_t'
>>> ../arch/powerpc/boot/types.h:22:13: note: previous declaration of 'uint64_t' was here
>>> ../arch/powerpc/boot/Makefile:210: recipe for target 'arch/powerpc/boot/fdt.o' failed
>>> make[2]: *** [arch/powerpc/boot/fdt.o] Error 1
>>>
>>> The problem is that commit 656ad58ef19e (powerpc/boot: Add OPAL console
>>> to epapr wrappers) adds typedefs for uint32_t and uint64_t to type.h but
>>> doesn't remove the pre-existing (and now duplicate) typedefs from
>>> libfdt_env.h. Fix the error by removing the duplicat typedefs from
>>> libfdt_env.h
>>>
>>> CC: David Gibson <david@gibson.dropbear.id.au>
>>> CC: Oliver O'Halloran <oohall@gmail.com>
>>> Signed-off-by: Mark Greer <mgreer@animalcreek.com>
>>> ---
>>> Having said all of that, commit 656ad58ef19e (powerpc/boot: Add OPAL
>>> console to epapr wrappers) went into mainline back in 2016 so, AFAICT,
>>> this has been broken since then. That seems unlikely so I must be
>>> missing something... Any ideas what that is?
>>
>> I just compiled uImage for ppc6xx_defconfig, and I don't get such error.
>> I looked at what gcc -E outputs, u32 is defined twice but it doesn't seems
>> to bother GCC.
>>
>> What version of GCC do you use ?
>> I tried with 5.4.0 and 4.6.3, both seems to work.
>>
>> Christophe
>
> Hi Christophe.
>
> That's interesting. I would expect an error regardless of version.
>
> I used an old 4.5.1 gcc that I had laying around (from denx, iirc).
> I'll find a newer one and try it.
>
> Either way, it seems to me that we should remove the duplicate definitions.
> Do you agree?
Yes I agree. I was however intrigued by your statement that compilation
should have been broken since 2016.
Christophe
>
> Thanks,
>
> Mark
> --
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* [PATCH AUTOSEL for 3.18 101/102] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP
From: Sasha Levin @ 2018-03-19 16:13 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Eric W. Biederman, Paul Mackerras, Kumar Gala, Michael Ellerman,
Benjamin Herrenschmidt, linuxppc-dev@lists.ozlabs.org,
Sasha Levin
In-Reply-To: <20180319161117.17833-1-alexander.levin@microsoft.com>
From: "Eric W. Biederman" <ebiederm@xmission.com>
[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code =3D=3D 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various ex=
ceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.=
git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
arch/powerpc/include/uapi/asm/siginfo.h | 15 +++++++++++++++
arch/powerpc/kernel/traps.c | 10 +++++-----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/siginfo.h b/arch/powerpc/include=
/uapi/asm/siginfo.h
index ccce3ef5cd86..9c437eaf7c21 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -17,4 +17,19 @@
#undef NSIGTRAP
#define NSIGTRAP 4
=20
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
#endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 0dc43f9932cf..6cc0280a8ae0 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -769,7 +769,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=3D%lx\n",
regs->nip, regs->msr, regs->trap);
=20
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
=20
exception_exit(prev_state);
}
@@ -791,7 +791,7 @@ void instruction_breakpoint_exception(struct pt_regs *r=
egs)
=20
void RunModeException(struct pt_regs *regs)
{
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
}
=20
void __kprobes single_step_exception(struct pt_regs *regs)
@@ -826,7 +826,7 @@ static void emulate_single_step(struct pt_regs *regs)
=20
static inline int __parse_fpscr(unsigned long fpscr)
{
- int ret =3D 0;
+ int ret =3D FPE_FIXME;
=20
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1742,7 +1742,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
- int code =3D 0;
+ int code =3D FPE_FIXME;
int err;
=20
flush_spe_to_thread(current);
@@ -1811,7 +1811,7 @@ void SPEFloatingPointRoundException(struct pt_regs *r=
egs)
printk(KERN_ERR "unrecognized spe instruction "
"in %s at %lx\n", current->comm, regs->nip);
} else {
- _exception(SIGFPE, regs, 0, regs->nip);
+ _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
}
--=20
2.14.1
^ permalink raw reply related
* [PATCH AUTOSEL for 4.4 166/167] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP
From: Sasha Levin @ 2018-03-19 16:08 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Eric W. Biederman, Paul Mackerras, Kumar Gala, Michael Ellerman,
Benjamin Herrenschmidt, linuxppc-dev@lists.ozlabs.org,
Sasha Levin
In-Reply-To: <20180319160513.16384-1-alexander.levin@microsoft.com>
From: "Eric W. Biederman" <ebiederm@xmission.com>
[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code =3D=3D 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various ex=
ceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.=
git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
arch/powerpc/include/uapi/asm/siginfo.h | 15 +++++++++++++++
arch/powerpc/kernel/traps.c | 10 +++++-----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/siginfo.h b/arch/powerpc/include=
/uapi/asm/siginfo.h
index ccce3ef5cd86..9c437eaf7c21 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -17,4 +17,19 @@
#undef NSIGTRAP
#define NSIGTRAP 4
=20
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
#endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index e4dcb0a43e3f..9ac9dfa6f796 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -771,7 +771,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=3D%lx\n",
regs->nip, regs->msr, regs->trap);
=20
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
=20
exception_exit(prev_state);
}
@@ -793,7 +793,7 @@ void instruction_breakpoint_exception(struct pt_regs *r=
egs)
=20
void RunModeException(struct pt_regs *regs)
{
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
}
=20
void __kprobes single_step_exception(struct pt_regs *regs)
@@ -828,7 +828,7 @@ static void emulate_single_step(struct pt_regs *regs)
=20
static inline int __parse_fpscr(unsigned long fpscr)
{
- int ret =3D 0;
+ int ret =3D FPE_FIXME;
=20
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1764,7 +1764,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
- int code =3D 0;
+ int code =3D FPE_FIXME;
int err;
=20
flush_spe_to_thread(current);
@@ -1833,7 +1833,7 @@ void SPEFloatingPointRoundException(struct pt_regs *r=
egs)
printk(KERN_ERR "unrecognized spe instruction "
"in %s at %lx\n", current->comm, regs->nip);
} else {
- _exception(SIGFPE, regs, 0, regs->nip);
+ _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
}
--=20
2.14.1
^ permalink raw reply related
* [PATCH AUTOSEL for 4.9 279/281] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP
From: Sasha Levin @ 2018-03-19 16:03 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Eric W. Biederman, Paul Mackerras, Kumar Gala, Michael Ellerman,
Benjamin Herrenschmidt, linuxppc-dev@lists.ozlabs.org,
Sasha Levin
In-Reply-To: <20180319155742.13731-1-alexander.levin@microsoft.com>
From: "Eric W. Biederman" <ebiederm@xmission.com>
[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code =3D=3D 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various ex=
ceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.=
git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
arch/powerpc/include/uapi/asm/siginfo.h | 15 +++++++++++++++
arch/powerpc/kernel/traps.c | 10 +++++-----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/siginfo.h b/arch/powerpc/include=
/uapi/asm/siginfo.h
index ccce3ef5cd86..9c437eaf7c21 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -17,4 +17,19 @@
#undef NSIGTRAP
#define NSIGTRAP 4
=20
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
#endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 43021f8e47a6..7e5b0bbbe4c8 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -793,7 +793,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=3D%lx\n",
regs->nip, regs->msr, regs->trap);
=20
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
=20
exception_exit(prev_state);
}
@@ -815,7 +815,7 @@ void instruction_breakpoint_exception(struct pt_regs *r=
egs)
=20
void RunModeException(struct pt_regs *regs)
{
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
}
=20
void single_step_exception(struct pt_regs *regs)
@@ -851,7 +851,7 @@ static void emulate_single_step(struct pt_regs *regs)
=20
static inline int __parse_fpscr(unsigned long fpscr)
{
- int ret =3D 0;
+ int ret =3D FPE_FIXME;
=20
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1855,7 +1855,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
- int code =3D 0;
+ int code =3D FPE_FIXME;
int err;
=20
flush_spe_to_thread(current);
@@ -1924,7 +1924,7 @@ void SPEFloatingPointRoundException(struct pt_regs *r=
egs)
printk(KERN_ERR "unrecognized spe instruction "
"in %s at %lx\n", current->comm, regs->nip);
} else {
- _exception(SIGFPE, regs, 0, regs->nip);
+ _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
}
--=20
2.14.1
^ permalink raw reply related
* Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h
From: Mark Greer @ 2018-03-19 16:02 UTC (permalink / raw)
To: Christophe LEROY
Cc: Mark Greer, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Oliver O'Halloran, linuxppc-dev,
David Gibson
In-Reply-To: <e710d9d7-232b-6420-96a7-8167dd91b824@c-s.fr>
On Mon, Mar 19, 2018 at 09:53:09AM +0100, Christophe LEROY wrote:
>
>
> Le 16/03/2018 à 22:54, Mark Greer a écrit :
> >When building a uImage or zImage using ppc6xx_defconfig and some other
> >defconfigs, the following error occurs:
> >
> > BOOTCC arch/powerpc/boot/fdt.o
> > In file included from arch/powerpc/boot/fdt.c:51:0:
> > ../arch/powerpc/boot/libfdt_env.h:10:13: error: redefinition of typedef 'uint32_t'
> > ../arch/powerpc/boot/types.h:21:13: note: previous declaration of 'uint32_t' was here
> > ../arch/powerpc/boot/libfdt_env.h:11:13: error: redefinition of typedef 'uint64_t'
> > ../arch/powerpc/boot/types.h:22:13: note: previous declaration of 'uint64_t' was here
> > ../arch/powerpc/boot/Makefile:210: recipe for target 'arch/powerpc/boot/fdt.o' failed
> > make[2]: *** [arch/powerpc/boot/fdt.o] Error 1
> >
> >The problem is that commit 656ad58ef19e (powerpc/boot: Add OPAL console
> >to epapr wrappers) adds typedefs for uint32_t and uint64_t to type.h but
> >doesn't remove the pre-existing (and now duplicate) typedefs from
> >libfdt_env.h. Fix the error by removing the duplicat typedefs from
> >libfdt_env.h
> >
> >CC: David Gibson <david@gibson.dropbear.id.au>
> >CC: Oliver O'Halloran <oohall@gmail.com>
> >Signed-off-by: Mark Greer <mgreer@animalcreek.com>
> >---
> >Having said all of that, commit 656ad58ef19e (powerpc/boot: Add OPAL
> >console to epapr wrappers) went into mainline back in 2016 so, AFAICT,
> >this has been broken since then. That seems unlikely so I must be
> >missing something... Any ideas what that is?
>
> I just compiled uImage for ppc6xx_defconfig, and I don't get such error.
> I looked at what gcc -E outputs, u32 is defined twice but it doesn't seems
> to bother GCC.
>
> What version of GCC do you use ?
> I tried with 5.4.0 and 4.6.3, both seems to work.
>
> Christophe
Hi Christophe.
That's interesting. I would expect an error regardless of version.
I used an old 4.5.1 gcc that I had laying around (from denx, iirc).
I'll find a newer one and try it.
Either way, it seems to me that we should remove the duplicate definitions.
Do you agree?
Thanks,
Mark
--
^ permalink raw reply
* [PATCH AUTOSEL for 4.14 93/97] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP
From: Sasha Levin @ 2018-03-19 15:56 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Eric W. Biederman, Paul Mackerras, Kumar Gala, Michael Ellerman,
Benjamin Herrenschmidt, linuxppc-dev@lists.ozlabs.org,
Sasha Levin
In-Reply-To: <20180319155411.12348-1-alexander.levin@microsoft.com>
From: "Eric W. Biederman" <ebiederm@xmission.com>
[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code =3D=3D 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various ex=
ceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.=
git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
arch/powerpc/include/uapi/asm/siginfo.h | 15 +++++++++++++++
arch/powerpc/kernel/traps.c | 10 +++++-----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/siginfo.h b/arch/powerpc/include=
/uapi/asm/siginfo.h
index 1a691141e49f..444ca6c9989a 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -18,4 +18,19 @@
#undef NSIGTRAP
#define NSIGTRAP 4
=20
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
#endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 13c9dcdcba69..f6f6d4bf147c 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -720,7 +720,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=3D%lx\n",
regs->nip, regs->msr, regs->trap);
=20
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
=20
exception_exit(prev_state);
}
@@ -742,7 +742,7 @@ void instruction_breakpoint_exception(struct pt_regs *r=
egs)
=20
void RunModeException(struct pt_regs *regs)
{
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
}
=20
void single_step_exception(struct pt_regs *regs)
@@ -781,7 +781,7 @@ static void emulate_single_step(struct pt_regs *regs)
=20
static inline int __parse_fpscr(unsigned long fpscr)
{
- int ret =3D 0;
+ int ret =3D FPE_FIXME;
=20
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1769,7 +1769,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
- int code =3D 0;
+ int code =3D FPE_FIXME;
int err;
=20
flush_spe_to_thread(current);
@@ -1838,7 +1838,7 @@ void SPEFloatingPointRoundException(struct pt_regs *r=
egs)
printk(KERN_ERR "unrecognized spe instruction "
"in %s at %lx\n", current->comm, regs->nip);
} else {
- _exception(SIGFPE, regs, 0, regs->nip);
+ _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
}
--=20
2.14.1
^ permalink raw reply related
* [PATCH AUTOSEL for 4.15 120/124] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP
From: Sasha Levin @ 2018-03-19 15:49 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Eric W. Biederman, Paul Mackerras, Kumar Gala, Michael Ellerman,
Benjamin Herrenschmidt, linuxppc-dev@lists.ozlabs.org,
Sasha Levin
In-Reply-To: <20180319154645.11350-1-alexander.levin@microsoft.com>
From: "Eric W. Biederman" <ebiederm@xmission.com>
[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code =3D=3D 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kumar Gala <kumar.gala@freescale.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various ex=
ceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.=
git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
arch/powerpc/include/uapi/asm/siginfo.h | 15 +++++++++++++++
arch/powerpc/kernel/traps.c | 10 +++++-----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/uapi/asm/siginfo.h b/arch/powerpc/include=
/uapi/asm/siginfo.h
index 1a691141e49f..444ca6c9989a 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -18,4 +18,19 @@
#undef NSIGTRAP
#define NSIGTRAP 4
=20
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
#endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index f3eb61be0d30..f2e6e1838952 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -917,7 +917,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=3D%lx\n",
regs->nip, regs->msr, regs->trap);
=20
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
=20
exception_exit(prev_state);
}
@@ -939,7 +939,7 @@ void instruction_breakpoint_exception(struct pt_regs *r=
egs)
=20
void RunModeException(struct pt_regs *regs)
{
- _exception(SIGTRAP, regs, 0, 0);
+ _exception(SIGTRAP, regs, TRAP_FIXME, 0);
}
=20
void single_step_exception(struct pt_regs *regs)
@@ -978,7 +978,7 @@ static void emulate_single_step(struct pt_regs *regs)
=20
static inline int __parse_fpscr(unsigned long fpscr)
{
- int ret =3D 0;
+ int ret =3D FPE_FIXME;
=20
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1929,7 +1929,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
- int code =3D 0;
+ int code =3D FPE_FIXME;
int err;
=20
flush_spe_to_thread(current);
@@ -1998,7 +1998,7 @@ void SPEFloatingPointRoundException(struct pt_regs *r=
egs)
printk(KERN_ERR "unrecognized spe instruction "
"in %s at %lx\n", current->comm, regs->nip);
} else {
- _exception(SIGFPE, regs, 0, regs->nip);
+ _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
}
--=20
2.14.1
^ permalink raw reply related
* Re: [PATCH v12 00/11] Application Data Integrity feature introduced by SPARC M7
From: Khalid Aziz @ 2018-03-19 15:19 UTC (permalink / raw)
To: David Miller
Cc: dave.hansen, aarcange, akpm, allen.pais, aneesh.kumar,
anthony.yznaga, arnd, benh, bob.picco, bsingharora, corbet,
dan.j.williams, dave.jiang, david.j.aldridge, dwindsor, ebiederm,
elena.reshetova, gregkh, hannes, henry.willard, hpa, hughd,
imbrenda, jack, jag.raman, jane.chu, jglisse, jroedel, khalid,
khandual, kirill.shutemov, kstewart, ktkhai, liam.merwick,
linux-arch, linux-doc, linux-kernel, linux-mm, linuxppc-dev,
linuxram, linux, me, mgorman, mgorman, mhocko, mike.kravetz,
minchan, mingo
In-Reply-To: <20180318.110857.1660518649370410007.davem@davemloft.net>
On 03/18/2018 09:08 AM, David Miller wrote:
> In uapi/asm/auxvec.h you conditionalize the ADI aux vectors on
> CONFIG_SPARC64.
>
> That's not correct, you should never control user facing definitions
> based upon kernel configuration.
>
> Also, both 32-bit and 64-bit applications running on ADI capable
> machines want to compile against and use this informaiton.
>
> So please remove these CPP checks.
>
Hi Dave,
That makes sense. I will send a patch to remove these.
Thanks,
Khalid
^ permalink raw reply
* Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths
From: Steven Rostedt @ 2018-03-19 14:13 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Michael Ellerman, Paul Mackerras, linuxppc-dev,
Benjamin Herrenschmidt, Anton Blanchard, Nicholas Piggin,
sathnaga
In-Reply-To: <cdbe15845a5da965878b6344f69b6ed6dbabb87b.1521449527.git.naveen.n.rao@linux.vnet.ibm.com>
On Mon, 19 Mar 2018 14:43:00 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> index 3f3e81852422..fdf702b4df25 100644
> --- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> +++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> @@ -60,6 +60,19 @@ _GLOBAL(ftrace_caller)
> mfxer r10
> mfcr r11
>
> +#ifdef CONFIG_KVM
> + lbz r3, PACA_FTRACE_DISABLED(r13)
> + cmpdi r3, 0
> + beq 1f
> + mflr r3
> + mtctr r3
> + REST_GPR(3, r1)
> + addi r1, r1, SWITCH_FRAME_SIZE
> + mtlr r0
> + bctr
> +1:
> +#endif
I wonder if we should try to move the return out of the fast path (for
cache reasons), as most of the time the above compare will be true. That
is:
#ifdef CONFIG_KVM
lbz r3, PACA_FTRACE_DISABLED(r13)
cmpdi r3, 0
bne no_trace
#endif
/* rest of ftrace_caller code */
/* after ftrace_caller... */
bctr /* jump after _mcount site */
#ifdef CONFIG_KVM
no_trace:
mflr r3
mtctr r3
REST_GPR(3, r1)
addi r1, r1, SWITCH_FRAME_SIZE
mtlr r0
bctr
#endif
-- Steve
> +
> /* Get the _mcount() call site out of LR */
> mflr r7
> /* Save it as pt_regs->nip */
^ permalink raw reply
* [PATCH 2/2] powerpc: avoid an unnecessary test and branch in longjmp()
From: Christophe Leroy @ 2018-03-19 12:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <8c39109dbf91dd464fee381da3d8ad3354273ed2.1521461897.git.christophe.leroy@c-s.fr>
Doing the test at exit of the function avoids an unnecessary
test and branch in longjmp()
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/misc.S | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 739977a6be80..9b9207f60d28 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -90,14 +90,11 @@ _GLOBAL(setjmp)
blr
_GLOBAL(longjmp)
- PPC_LCMPI r4,0
- bne 1f
- li r4,1
#if defined(CONFIG_PPC32) && defined(CONFIG_CPU_BIG_ENDIAN)
-1: lmw r12, 3*SZL(r3)
+ lmw r12, 3*SZL(r3)
mtcrf 0x38, r12
#else
-1: PPC_LL r13,4*SZL(r3)
+ PPC_LL r13,4*SZL(r3)
PPC_LL r14,5*SZL(r3)
PPC_LL r15,6*SZL(r3)
PPC_LL r16,7*SZL(r3)
@@ -123,7 +120,9 @@ _GLOBAL(longjmp)
PPC_LL r1,SZL(r3)
PPC_LL r2,2*SZL(r3)
mtlr r0
- mr r3,r4
+ mr. r3, r4
+ bnelr
+ li r3, 1
blr
_GLOBAL(current_stack_pointer)
--
2.13.3
^ permalink raw reply related
* [PATCH 1/2] powerpc/32be: use stmw/lmw for non volatile registers save/restore
From: Christophe Leroy @ 2018-03-19 12:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood
Cc: linux-kernel, linuxppc-dev
arch/powerpc/Makefile activates -mmultiple on BE PPC32 configs
in order to use multiple word instructions in functions entry/exit
The patch does the same for the asm parts, for consistency
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/include/asm/ppc_asm.h | 5 +++++
arch/powerpc/kernel/misc.S | 10 ++++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index ae94b3626b6c..3c39f7fa9540 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -80,11 +80,16 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
#else
#define SAVE_GPR(n, base) stw n,GPR0+4*(n)(base)
#define REST_GPR(n, base) lwz n,GPR0+4*(n)(base)
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define SAVE_NVGPRS(base) stmw 13, GPR0+4*13(base)
+#define REST_NVGPRS(base) lmw 13, GPR0+4*13(base)
+#else
#define SAVE_NVGPRS(base) SAVE_GPR(13, base); SAVE_8GPRS(14, base); \
SAVE_10GPRS(22, base)
#define REST_NVGPRS(base) REST_GPR(13, base); REST_8GPRS(14, base); \
REST_10GPRS(22, base)
#endif
+#endif
#define SAVE_2GPRS(n, base) SAVE_GPR(n, base); SAVE_GPR(n+1, base)
#define SAVE_4GPRS(n, base) SAVE_2GPRS(n, base); SAVE_2GPRS(n+2, base)
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 384357cb8bc0..739977a6be80 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -60,6 +60,10 @@ _GLOBAL(setjmp)
PPC_STL r0,0(r3)
PPC_STL r1,SZL(r3)
PPC_STL r2,2*SZL(r3)
+#if defined(CONFIG_PPC32) && defined(CONFIG_CPU_BIG_ENDIAN)
+ mfcr r12
+ stmw r12, 3*SZL(r3)
+#else
mfcr r0
PPC_STL r0,3*SZL(r3)
PPC_STL r13,4*SZL(r3)
@@ -81,6 +85,7 @@ _GLOBAL(setjmp)
PPC_STL r29,20*SZL(r3)
PPC_STL r30,21*SZL(r3)
PPC_STL r31,22*SZL(r3)
+#endif
li r3,0
blr
@@ -88,6 +93,10 @@ _GLOBAL(longjmp)
PPC_LCMPI r4,0
bne 1f
li r4,1
+#if defined(CONFIG_PPC32) && defined(CONFIG_CPU_BIG_ENDIAN)
+1: lmw r12, 3*SZL(r3)
+ mtcrf 0x38, r12
+#else
1: PPC_LL r13,4*SZL(r3)
PPC_LL r14,5*SZL(r3)
PPC_LL r15,6*SZL(r3)
@@ -109,6 +118,7 @@ _GLOBAL(longjmp)
PPC_LL r31,22*SZL(r3)
PPC_LL r0,3*SZL(r3)
mtcrf 0x38,r0
+#endif
PPC_LL r0,0(r3)
PPC_LL r1,SZL(r3)
PPC_LL r2,2*SZL(r3)
--
2.13.3
^ permalink raw reply related
* Linux 4.16: Reported regressions as of , 2018-03-19 (Was: Re: Linux 4.16-rc6)
From: Thorsten Leemhuis @ 2018-03-19 11:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Jonathan Corbet
In-Reply-To: <CA+55aFzV1nffUeriZLksK90noD49T+w+WmgBsYMAO13rTbn3Pg@mail.gmail.com>
On 19.03.2018 02:14, Linus Torvalds wrote:
> This has been a nice quiet week, so rc6 is pretty tiny. Everything
> looks like we're on a usual schedule - I'll make an rc7, but hopefully
> that will be it.
Hi! Find below my fifth regression report for Linux 4.16. It lists 7
regressions I'm currently aware of. 2 were fixed since last weeks
report; 1 is new; 2 are going to be removed (see below for details).
Are you aware of any other regressions that got introduced this
development cycle? Then please let me know by mail (a simple bounce or
forward to the sender of this email address is enough!). And please tell
me if there is anything in the report that shouldn't be there.
Ciao, Thorsten
== Current regressions ==
Dell R640 does not boot due to SCSI/SATA failure
- Status: WIP; some other changes developed for 4.17 solve this
regression, but there is a discussion for a proper fix
- Cause: https://git.kernel.org/torvalds/c/84676c1f21e8
- Reported: 2018-02-22
https://marc.info/?l=linux-kernel&m=151931128006031
- Last known developer activity: 2018-03-14
https://marc.info/?l=linux-block&m=152102086831636&w=2
- Other relevant links:
https://marc.info/?l=linux-block&m=152051511802229&w=2
https://marc.info/?l=linux-kernel&m=152026091325037
hci_bcm: Streamline runtime PM code change for 4.16 kernel breaks
bluetooth on ASUS T100TA
- Status: Hans is working on it, lot's of activity in bugzilla
- Cause: https://git.kernel.org/torvalds/c/43fff7683468
- Reported: 2018-03-01
https://bugzilla.kernel.org/show_bug.cgi?id=198953
Error updating SMART data during runtime and could not connect to lv
["Possible Regression"]
- Status: Two issues discussed here; not much progress yet on the
regression (latency issues in the MU03 version of the firmware,
triggered by polling SMART data, which causes lvmetad to timeout in some
cases)
- Reported: 2018-03-11
https://marc.info/?l=linux-kernel&m=152075643627082
https://bugzilla.kernel.org/show_bug.cgi?id=199077
- Last known developer activity: 2018-03-19
https://marc.info/?l=linux-kernel&m=152145306610330
- Other relevant links:
https://www.mail-archive.com/linux-block@vger.kernel.org/msg18338.html
https://marc.info/?l=linux-scsi&m=152095303312164&w=2
15% longer running times on lvm2 test suite
- Status: Seems the real problem is in the way the test scripts interact
with the kernel
- Cause: https://git.kernel.org/torvalds/c/44c02a2c3dc5
- Reported: 2018-03-11
https://marc.info/?l=linux-kernel&m=152077333230274
- Last known developer activity: 2018-03-13
https://marc.info/?l=linux-kernel&m=152097761921525
sdhci-acpi not recognizing eMMC
- Status: Told reporter to contact developers an ML by mail
- Cause: https://git.kernel.org/torvalds/c/1b7ba57ecc86
- Reported: 2018-03-13
https://bugzilla.kernel.org/show_bug.cgi?id=199105
== Waiting for clarification from reporter ==
Interrupt storm after suspend causes one busy kworker
- Status: Still waiting for data from reporter
- Reported: 2018-02-25
https://bugzilla.kernel.org/show_bug.cgi?id=198929
AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5
- Status: New, but data missing; unclear if this really is a regression
in 4.16, but looks a lot like one
- Reported: 2018-03-13
https://bugzilla.kernel.org/show_bug.cgi?id=199101
== Going to get removed from the report ==
aim7.jobs-per-min -18.0% regression
- Status: not an issue; looks like something weird happen when compiling
the kernel which lead to bogus results
- Cause: https://git.kernel.org/torvalds/c/c0cef30e4ff0
- Reported: 2018-02-25
https://marc.info/?l=linux-kernel&m=151957120702272&w=2
- Last known developer activity:
https://marc.info/?l=linux-kernel&m=152113601602820
[mm, mlock, vmscan] 9c4e6b1a70: stress-ng.hdd.ops_per_sec -7.9% regression
- Status: looks stalled, seems nobody cares; side note: lkp-robot warned
about something else triggered by the same commit:
https://lkml.kernel.org/r/20180302093940.GE25699@yexl-desktop is related
- Cause: https://git.kernel.org/torvalds/c/9c4e6b1a7027
- Reported: 2018-02-25
https://marc.info/?l=linux-kernel&m=151956997301994
- Note: performance regression found by lkp-robot
== Fixed since last report ==
Regression from efi: call get_event_log before ExitBootServices
- Status: Fixed by https://git.kernel.org/torvalds/c/79832f0b5f71
- Cause: https://git.kernel.org/torvalds/c/33b6d03469b2
- Reported: 2018-03-06
https://marc.info/?l=linux-kernel&m=152035206220237&w=2
[amdgpu CARRIZO] disabled backlight after S3 resume
- Status: Fixed by https://git.kernel.org/torvalds/c/b5e324131697
- Cause: https://git.kernel.org/torvalds/c/4ec6ecf48c64
- Reported: 2018-03-07
https://bugzilla.kernel.org/show_bug.cgi?id=199047
^ permalink raw reply
* Re: [PATCH 3/5] powerpc/mm/32: Use page_is_ram to check for RAM
From: Michael Ellerman @ 2018-03-19 11:19 UTC (permalink / raw)
To: Jonathan Neuschäfer, linuxppc-dev
Cc: linux-kernel, Jonathan Neuschäfer, linux-mm, Paul Mackerras,
Joel Stanley, Guenter Roeck
In-Reply-To: <874llcha6p.fsf@concordia.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Jonathan Neusch=C3=A4fer <j.neuschaefer@gmx.net> writes:
>
>> Signed-off-by: Jonathan Neusch=C3=A4fer <j.neuschaefer@gmx.net>
>> ---
>> arch/powerpc/mm/pgtable_32.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
>> index d35d9ad3c1cd..d54e1a9c1c99 100644
>> --- a/arch/powerpc/mm/pgtable_32.c
>> +++ b/arch/powerpc/mm/pgtable_32.c
>> @@ -145,9 +145,8 @@ __ioremap_caller(phys_addr_t addr, unsigned long siz=
e, unsigned long flags,
>> #ifndef CONFIG_CRASH_DUMP
>> /*
>> * Don't allow anybody to remap normal RAM that we're using.
>> - * mem_init() sets high_memory so only do the check after that.
>> */
>> - if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
>> + if (page_is_ram(__phys_to_pfn(p)) &&
>> !(__allow_ioremap_reserved && memblock_is_region_reserved(p, size)=
)) {
>> printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
>> (unsigned long long)p, __builtin_return_address(0));
>
>
> This is killing my p5020ds (Freescale e5500) unfortunately:
Duh, I should actually read the patch :)
This is a 32-bit system with 4G of RAM, so not all of RAM is mapped,
some of it is highem which is why removing the test against high_memory
above breaks it.
So I need the high_memory test on this system.
I'm not clear why it was a problem for you on the Wii, do you even build
the Wii kernel with HIGHMEM enabled?
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths
From: Nicholas Piggin @ 2018-03-19 10:40 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Steven Rostedt, Michael Ellerman, Paul Mackerras, linuxppc-dev,
Benjamin Herrenschmidt, Anton Blanchard, sathnaga
In-Reply-To: <cdbe15845a5da965878b6344f69b6ed6dbabb87b.1521449527.git.naveen.n.rao@linux.vnet.ibm.com>
On Mon, 19 Mar 2018 14:43:00 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> We have some C code that we call into from real mode where we cannot
> take any exceptions. Though the C functions themselves are mostly safe,
> if these functions are traced, there is a possibility that we may take
> an exception. For instance, in certain conditions, the ftrace code uses
> WARN(), which uses a 'trap' to do its job.
>
> For such scenarios, introduce a new field in paca 'ftrace_disabled',
> which is checked on ftrace entry before continuing. This field can then
> be set to a non-zero value to disable/pause ftrace, and reset to zero to
> resume ftrace.
>
> Since KVM is the only user for this currently, we guard the
> ftrace/mcount checks within CONFIG_KVM. This can later be removed
> if/when there are other users.
Why not test HSTATE_IN_GUEST then? Add ftrace_disabled if non-KVM users
come along.
Thanks,
Nick
^ permalink raw reply
* [PATCH 2/2] powerpc/mm: Trace tlbia instruction
From: Christophe Leroy @ 2018-03-19 10:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood
Cc: linux-kernel, linuxppc-dev, Balbir Singh
In-Reply-To: <4ffd3d6143f991615ffe07f43952cbc62163d319.1521452718.git.christophe.leroy@c-s.fr>
Add a trace point for tlbia (Translation Lookaside Buffer Invalidate
All) instruction.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/include/asm/trace.h | 15 +++++++++++++++
arch/powerpc/mm/mmu_decl.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/arch/powerpc/include/asm/trace.h b/arch/powerpc/include/asm/trace.h
index 33f3b479138b..d1d63b173dd7 100644
--- a/arch/powerpc/include/asm/trace.h
+++ b/arch/powerpc/include/asm/trace.h
@@ -202,6 +202,21 @@ TRACE_EVENT(tlbie,
__entry->r)
);
+TRACE_EVENT(tlbia,
+
+ TP_PROTO(unsigned long lpid),
+ TP_ARGS(lpid),
+ TP_STRUCT__entry(
+ __field(unsigned long, lpid)
+ ),
+
+ TP_fast_assign(
+ __entry->lpid = lpid;
+ ),
+
+ TP_printk("lpid=%ld", __entry->lpid)
+);
+
#endif /* _TRACE_POWERPC_H */
#undef TRACE_INCLUDE_PATH
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index b9991e0c61a2..d4ae7b5d45fe 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -32,10 +32,12 @@
static inline void _tlbil_all(void)
{
asm volatile ("sync; tlbia; isync" : : : "memory");
+ trace_tlbia(MMU_NO_CONTEXT);
}
static inline void _tlbil_pid(unsigned int pid)
{
asm volatile ("sync; tlbia; isync" : : : "memory");
+ trace_tlbia(pid);
}
#define _tlbil_pid_noind(pid) _tlbil_pid(pid)
--
2.13.3
^ permalink raw reply related
* [PATCH 1/2] powerpc/mm: Add missing tracepoint for tlbie
From: Christophe Leroy @ 2018-03-19 10:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood
Cc: linux-kernel, linuxppc-dev, Balbir Singh
commit 0428491cba927 ("powerpc/mm: Trace tlbie(l) instructions")
added tracepoints for tlbie calls, but _tlbil_va() was forgotten
Fixes: 0428491cba927 ("powerpc/mm: Trace tlbie(l) instructions")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/mmu_decl.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 57fbc554c785..b9991e0c61a2 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -21,6 +21,7 @@
#include <linux/mm.h>
#include <asm/tlbflush.h>
#include <asm/mmu.h>
+#include <asm/trace.h>
#ifdef CONFIG_PPC_MMU_NOHASH
@@ -56,6 +57,7 @@ static inline void _tlbil_va(unsigned long address, unsigned int pid,
unsigned int tsize, unsigned int ind)
{
asm volatile ("tlbie %0; sync" : : "r" (address) : "memory");
+ trace_tlbie(pid, 0, address, 0, 0, 0, 0);
}
#elif defined(CONFIG_PPC_BOOK3E)
extern void _tlbil_va(unsigned long address, unsigned int pid,
--
2.13.3
^ permalink raw reply related
* Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation
From: Ingo Molnar @ 2018-03-19 9:29 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Dominik Brodowski, Linux Kernel Mailing List,
Arnd Bergmann, linux-arch, Ralf Baechle, James Hogan, linux-mips,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, ppc-dev,
Martin Schwidefsky, Heiko Carstens, linux-s390, David S . Miller,
sparclinux, Ingo Molnar, Jiri Slaby, the arch/x86 maintainers
In-Reply-To: <20180319042300.GW30522@ZenIV.linux.org.uk>
* Al Viro <viro@ZenIV.linux.org.uk> wrote:
> On Sun, Mar 18, 2018 at 06:18:48PM +0000, Al Viro wrote:
>
> > I'd done some digging in that area, will find the notes and post.
>
> OK, found:
Very nice writeup - IMHO this should go into Documentation/!
> OTOH, consider arm. There we have
> * r0, r1, r2, r3, [sp,#8], [sp,#12], [sp,#16]... is the sequence
> of objects used to pass arguments
> * 32bit and less - pick the next available slot
> * 64bit - skip a slot if we'd already taken an odd number, then use
> the next two slots for lower and upper 32 bits of the argument.
>
> So our classes take
> simple n-argument: 0 to 6 slots
> WD 4 slots
> DWW 4 slots
> WDW 5 slots
> WWDD 6 slots
> WDWW 5 slots
> WWWD 6 slots
> WWDWW 6 slots
> WDDW 7 slots (!) Also ****, !!!!, !@#!@#!@#!# and other nice
> and well-deserved comments from arch maintainers, some of them even printable:
> /* It would be nice if people remember that not all the world's an i386
> when they introduce new system calls */
> SYSCALL_DEFINE4(sync_file_range2, int, fd, unsigned int, flags,
> loff_t, offset, loff_t, nbytes)
Such idiosyncratic platform quirks that have an impact on generic code should be
as self-maintaining as possible: i.e. there should be a build time warning even on
x86 if someone introduces a new, suboptimally packed system call.
Otherwise we'll have such incidents again and again as new system calls get added.
> [snip the preprocessor horrors - the sketches I've got there are downright obscene]
I still think we should consider creating a generic facility and a tool: which
would immediately and automatically add new system calls to *every* architecture -
or which would initially at least check these syscall ABI constraints.
I.e. this would start with a new generic kernel facility that warns about
suboptimal new system call argument layouts on every architecture, not just on the
affected ones.
That's a significant undertaking but should be possible to do.
Once such a facility is in place all the existing old mess is still a PITA, but
should be manageable eventually - as no new mess is added to it.
IMHO that's the only thing that could break the somewhat deadly current dynamic of
system call mappings mess. Complaining about people not knowing about quirks won't
help.
One way to implement this would be to put the argument chain types (string) and
sizes (int) into a special debug section which isn't included in the final kernel
image but which can be checked at link time.
For example this attempt at creating a new system call:
SYSCALL_DEFINE3(moron, int, fd, loff_t, offset, size_t, count)
... would translate into something like:
.name = "moron", .pattern = "WWW", .type = "int", .size = 4,
.name = NULL, .type = "loff_t", .size = 8,
.name = NULL, .type = "size_t", .size = 4,
.name = NULL, .type = NULL, .size = 0, /* end of parameter list */
i.e. "WDW". The build-time constraint checker could then warn about:
# error: System call "moron" uses invalid 'WWW' argument mapping for a 'WDW' sequence
# please avoid long-long arguments or use 'SYSCALL_DEFINE3_WDW()' instead
Each architecture can provide its own syscall parameter checking logic. Both
'stack boundary' and parameter packing rules would be straightforward to express
if we had such a data structure.
Also note that this tool could also check for optimum packing, i.e. if the new
system call is defined as:
SYSCALL_DEFINE3_WDW(moron, int, fd, loff_t, offset, size_t, count)
... would translate to something like:
.name = "moron", .pattern = "WDW", .type = "int", .size = 4,
.name = NULL, .type = "loff_t", .size = 8,
.name = NULL, .type = "size_t", .size = 4,
.name = NULL, .type = NULL, .size = 0, /* end of parameter list */
where the tool would print out this error:
# error: System call "moron" uses suboptimal 'WDW' argument mapping instead of 'WWD'
there would be a whitelist of existing system calls that are already using an
suboptimal argument order - but the warnings/errors would trigger for all new
system calls.
But adding non-straight-mapped system calls would be the exception in any case.
Such tooling could also do other things, such as limit the C types used for system
call defines to a well-chosen set of ABI-safe types, such as:
3 key_t
3 uint32_t
4 aio_context_t
4 mqd_t
4 timer_t
10 clockid_t
10 gid_t
10 loff_t
10 long
10 old_gid_t
10 old_uid_t
10 umode_t
11 uid_t
31 pid_t
34 size_t
69 unsigned int
130 unsigned long
226 int
This would also allow us some cleanups as well, such as dropping the pointless
'const' from arithmetic types in syscall definitions for example.
etc.
Basically this tool would be a secondary parser of the syscall arguments, with
most of the parsing and type sizing difficulties solved by the C parser already.
I think this problem could be much more sanely solved via annotations and a bit of
tooling, than trying to trick CPP into doing this for us (which won't really work
in any case).
Thanks,
Ingo
^ permalink raw reply
* [PATCH 2/2] powerpc64/ftrace: Disable ftrace during kvm guest entry/exit
From: Naveen N. Rao @ 2018-03-19 9:13 UTC (permalink / raw)
To: Steven Rostedt, Michael Ellerman, Paul Mackerras
Cc: linuxppc-dev, Benjamin Herrenschmidt, Anton Blanchard,
Nicholas Piggin, sathnaga
In-Reply-To: <cover.1521449527.git.naveen.n.rao@linux.vnet.ibm.com>
During guest entry/exit, we switch over to/from the guest MMU context.
While doing so, we set our state to KVM_GUEST_MODE_HOST_HV to note down
the fact that we cannot take any exceptions in the hypervisor code.
Since ftrace may be enabled and since it can result in us taking a trap,
disable ftrace by setting paca->ftrace_disabled. Once we exit the guest
and restore host MMU context, we re-enable ftrace.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index f31f357b8c5a..9292087adb68 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -600,6 +600,10 @@ kvmppc_hv_entry:
/* Save R1 in the PACA */
std r1, HSTATE_HOST_R1(r13)
+ /* Disable ftrace since we can't take a trap any more */
+ li r6, 1
+ stb r6, PACA_FTRACE_DISABLED(r13)
+
li r6, KVM_GUEST_MODE_HOST_HV
stb r6, HSTATE_IN_GUEST(r13)
@@ -2048,6 +2052,8 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX)
/* Unset guest mode */
li r0, KVM_GUEST_MODE_NONE
stb r0, HSTATE_IN_GUEST(r13)
+ li r0, 0
+ stb r0, PACA_FTRACE_DISABLED(r13)
ld r0, SFS+PPC_LR_STKOFF(r1)
addi r1, r1, SFS
@@ -3379,6 +3385,8 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX)
ld r8, KVM_HOST_LPCR(r10)
mtspr SPRN_LPCR, r8
isync
+ li r0, 0
+ stb r0, PACA_FTRACE_DISABLED(r13)
li r0, KVM_GUEST_MODE_NONE
stb r0, HSTATE_IN_GUEST(r13)
--
2.16.2
^ permalink raw reply related
* [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths
From: Naveen N. Rao @ 2018-03-19 9:13 UTC (permalink / raw)
To: Steven Rostedt, Michael Ellerman, Paul Mackerras
Cc: linuxppc-dev, Benjamin Herrenschmidt, Anton Blanchard,
Nicholas Piggin, sathnaga
In-Reply-To: <cover.1521449527.git.naveen.n.rao@linux.vnet.ibm.com>
We have some C code that we call into from real mode where we cannot
take any exceptions. Though the C functions themselves are mostly safe,
if these functions are traced, there is a possibility that we may take
an exception. For instance, in certain conditions, the ftrace code uses
WARN(), which uses a 'trap' to do its job.
For such scenarios, introduce a new field in paca 'ftrace_disabled',
which is checked on ftrace entry before continuing. This field can then
be set to a non-zero value to disable/pause ftrace, and reset to zero to
resume ftrace.
Since KVM is the only user for this currently, we guard the
ftrace/mcount checks within CONFIG_KVM. This can later be removed
if/when there are other users.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/paca.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 13 +++++++++++++
arch/powerpc/kernel/trace/ftrace_64_pg.S | 6 ++++++
4 files changed, 21 insertions(+)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index d2bf71dddbef..4f47adc2a408 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -211,6 +211,7 @@ struct paca_struct {
u16 in_mce;
u8 hmi_event_available; /* HMI event is available */
u8 hmi_p9_special_emu; /* HMI P9 special emulation */
+ u8 ftrace_disabled;
#endif
/* Stuff for accurate time accounting */
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index ea5eb91b836e..8e4fc96ff6bc 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -240,6 +240,7 @@ int main(void)
OFFSET(PACA_RFI_FLUSH_FALLBACK_AREA, paca_struct, rfi_flush_fallback_area);
OFFSET(PACA_EXRFI, paca_struct, exrfi);
OFFSET(PACA_L1D_FLUSH_SIZE, paca_struct, l1d_flush_size);
+ OFFSET(PACA_FTRACE_DISABLED, paca_struct, ftrace_disabled);
#endif
OFFSET(PACAHWCPUID, paca_struct, hw_cpu_id);
diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
index 3f3e81852422..fdf702b4df25 100644
--- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
+++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
@@ -60,6 +60,19 @@ _GLOBAL(ftrace_caller)
mfxer r10
mfcr r11
+#ifdef CONFIG_KVM
+ lbz r3, PACA_FTRACE_DISABLED(r13)
+ cmpdi r3, 0
+ beq 1f
+ mflr r3
+ mtctr r3
+ REST_GPR(3, r1)
+ addi r1, r1, SWITCH_FRAME_SIZE
+ mtlr r0
+ bctr
+1:
+#endif
+
/* Get the _mcount() call site out of LR */
mflr r7
/* Save it as pt_regs->nip */
diff --git a/arch/powerpc/kernel/trace/ftrace_64_pg.S b/arch/powerpc/kernel/trace/ftrace_64_pg.S
index f095358da96e..5b2a99129322 100644
--- a/arch/powerpc/kernel/trace/ftrace_64_pg.S
+++ b/arch/powerpc/kernel/trace/ftrace_64_pg.S
@@ -16,6 +16,12 @@
#ifdef CONFIG_DYNAMIC_FTRACE
_GLOBAL_TOC(ftrace_caller)
+#ifdef CONFIG_KVM
+ lbz r3, PACA_FTRACE_DISABLED(r13)
+ cmpdi r3, 0
+ bnelr
+#endif
+
/* Taken from output of objdump from lib64/glibc */
mflr r3
ld r11, 0(r1)
--
2.16.2
^ permalink raw reply related
* [PATCH 0/2] Disable ftrace during kvm guest entry/exit
From: Naveen N. Rao @ 2018-03-19 9:12 UTC (permalink / raw)
To: Steven Rostedt, Michael Ellerman, Paul Mackerras
Cc: linuxppc-dev, Benjamin Herrenschmidt, Anton Blanchard,
Nicholas Piggin, sathnaga
This is a follow on from the RFC posted at:
https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg130047.html
This series implements a new field in paca called 'ftrace_disabled' to
be set whenever we want to skip function tracing. This is currently only
used by KVM guest entry/exit and as such, it is guarded in CONFIG_KVM as
suggested by Steven Rostedt. This has had some minimal testing, and I
will continue to test it this week and report back if I see any issues.
- Naveen
Naveen N. Rao (2):
powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code
paths
powerpc64/ftrace: Disable ftrace during kvm guest entry/exit
arch/powerpc/include/asm/paca.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 13 +++++++++++++
arch/powerpc/kernel/trace/ftrace_64_pg.S | 6 ++++++
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 8 ++++++++
5 files changed, 29 insertions(+)
--
2.16.2
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h
From: Christophe LEROY @ 2018-03-19 8:53 UTC (permalink / raw)
To: Mark Greer, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: Oliver O'Halloran, linuxppc-dev, David Gibson
In-Reply-To: <20180316215443.2807-1-mgreer@animalcreek.com>
Le 16/03/2018 à 22:54, Mark Greer a écrit :
> When building a uImage or zImage using ppc6xx_defconfig and some other
> defconfigs, the following error occurs:
>
> BOOTCC arch/powerpc/boot/fdt.o
> In file included from arch/powerpc/boot/fdt.c:51:0:
> ../arch/powerpc/boot/libfdt_env.h:10:13: error: redefinition of typedef 'uint32_t'
> ../arch/powerpc/boot/types.h:21:13: note: previous declaration of 'uint32_t' was here
> ../arch/powerpc/boot/libfdt_env.h:11:13: error: redefinition of typedef 'uint64_t'
> ../arch/powerpc/boot/types.h:22:13: note: previous declaration of 'uint64_t' was here
> ../arch/powerpc/boot/Makefile:210: recipe for target 'arch/powerpc/boot/fdt.o' failed
> make[2]: *** [arch/powerpc/boot/fdt.o] Error 1
>
> The problem is that commit 656ad58ef19e (powerpc/boot: Add OPAL console
> to epapr wrappers) adds typedefs for uint32_t and uint64_t to type.h but
> doesn't remove the pre-existing (and now duplicate) typedefs from
> libfdt_env.h. Fix the error by removing the duplicat typedefs from
> libfdt_env.h
>
> CC: David Gibson <david@gibson.dropbear.id.au>
> CC: Oliver O'Halloran <oohall@gmail.com>
> Signed-off-by: Mark Greer <mgreer@animalcreek.com>
> ---
> Having said all of that, commit 656ad58ef19e (powerpc/boot: Add OPAL
> console to epapr wrappers) went into mainline back in 2016 so, AFAICT,
> this has been broken since then. That seems unlikely so I must be
> missing something... Any ideas what that is?
I just compiled uImage for ppc6xx_defconfig, and I don't get such error.
I looked at what gcc -E outputs, u32 is defined twice but it doesn't
seems to bother GCC.
What version of GCC do you use ?
I tried with 5.4.0 and 4.6.3, both seems to work.
Christophe
>
> I built all of the defconfigs that I had toolchains handy for (really
> just old-fashioned ppc32, non-booke) so I didn't test everything.
> Compile tested only as I no longer have any relevant hardware.
>
> Based on git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux fixes
> currently at e4b79900222b (powerpc/64s: Fix NULL AT_BASE_PLATFORM when
> using DT CPU features).
>
> arch/powerpc/boot/libfdt_env.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/libfdt_env.h b/arch/powerpc/boot/libfdt_env.h
> index f52c31b1f48f..2a0c8b1bf147 100644
> --- a/arch/powerpc/boot/libfdt_env.h
> +++ b/arch/powerpc/boot/libfdt_env.h
> @@ -7,8 +7,6 @@
>
> #include "of.h"
>
> -typedef u32 uint32_t;
> -typedef u64 uint64_t;
> typedef unsigned long uintptr_t;
>
> typedef __be16 fdt16_t;
>
^ permalink raw reply
* Re: [RFC PATCH 2/6] fs: provide a generic compat_sys_truncate64() implementation
From: Kevin Easton @ 2018-03-19 6:29 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-kernel, torvalds, arnd, viro, linux-arch, Ralf Baechle,
James Hogan, linux-mips, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, linuxppc-dev, Martin Schwidefsky,
Heiko Carstens, linux-s390, David S . Miller, sparclinux,
Ingo Molnar, Jiri Slaby, x86
In-Reply-To: <20180318161056.5377-3-linux@dominikbrodowski.net>
On Sun, Mar 18, 2018 at 05:10:52PM +0100, Dominik Brodowski wrote:
> The compat_sys_truncate64() implementations in mips, powerpc, s390, sparc
> and x86 only differed based on whether the u64 parameter needed padding
> and on its endianness.
>
...
> +#ifdef __ARCH_WANT_COMPAT_SYS_TRUNCATE64
> +#if defined(__ARCH_WANT_COMPAT_SYS_WITH_PADDING) && \
> + defined(__ARCH_WANT_LE_COMPAT_SYS)
> +COMPAT_SYSCALL_DEFINE4(truncate64, const char __user *, filename, u32 padding,
> + unsigned int, offset_low, unsigned int, offset_high)
> +#elif defined(__ARCH_WANT_COMPAT_SYS_WITH_PADDING) && \
> + !defined(__ARCH_WANT_LE_COMPAT_SYS)
> +COMPAT_SYSCALL_DEFINE4(truncate64, const char __user *, filename, u32 padding,
> + unsigned int, offset_high, unsigned int, offset_low)
Notwithstanding the other comments, shouldn't there be a comma between
'u32' and 'padding' in those?
- Kevin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox