* linux-next: manual merge of the powerpc tree with the asm-generic tree
From: Stephen Rothwell @ 2018-03-20 23:26 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, PowerPC, Arnd Bergmann
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Matt Brown
[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
lib/raid6/test/Makefile
between commit:
fa523d54a7eb ("raid: remove tile specific raid6 implementation")
from the asm-generic tree and commit:
751ba79cc552 ("lib/raid6/altivec: Add vpermxor implementation for raid6 Q syndrome")
from the powerpc 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 lib/raid6/test/Makefile
index fabc477b1417,5050e270c06b..000000000000
--- a/lib/raid6/test/Makefile
+++ b/lib/raid6/test/Makefile
@@@ -45,12 -45,17 +45,14 @@@ else ifeq ($(HAS_NEON),yes
CFLAGS += -DCONFIG_KERNEL_MODE_NEON=1
else
HAS_ALTIVEC := $(shell printf '\#include <altivec.h>\nvector int a;\n' |\
- gcc -c -x c - >&/dev/null && \
- rm ./-.o && echo yes)
+ gcc -c -x c - >/dev/null && rm ./-.o && echo yes)
ifeq ($(HAS_ALTIVEC),yes)
- OBJS += altivec1.o altivec2.o altivec4.o altivec8.o
+ CFLAGS += -I../../../arch/powerpc/include
+ CFLAGS += -DCONFIG_ALTIVEC
+ OBJS += altivec1.o altivec2.o altivec4.o altivec8.o \
+ vpermxor1.o vpermxor2.o vpermxor4.o vpermxor8.o
endif
endif
-ifeq ($(ARCH),tilegx)
-OBJS += tilegx8.o
-endif
.c.o:
$(CC) $(CFLAGS) -c -o $@ $<
@@@ -117,7 -137,8 +131,7 @@@ tables.c: mktable
./mktables > tables.c
clean:
- rm -f *.o *.a mktables mktables.c *.uc int*.c altivec*.c neon*.c tables.c raid6test
+ rm -f *.o *.a mktables mktables.c *.uc int*.c altivec*.c vpermxor*.c neon*.c tables.c raid6test
- rm -f tilegx*.c
spotless: clean
rm -f *~
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [bug?] Access was denied by memory protection keys in execute-only address
From: Ram Pai @ 2018-03-20 21:58 UTC (permalink / raw)
To: Li Wang
Cc: Michael Ellerman, Jan Stancek, ltp, linux-mm,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAEemH2czWDjvJLpL6ynV1+VxCFh_-A-d72tJhA5zwgrAES2nWA@mail.gmail.com>
On Fri, Mar 09, 2018 at 11:43:00AM +0800, Li Wang wrote:
> On Fri, Mar 9, 2018 at 12:45 AM, Ram Pai <[1]linuxram@us.ibm.com> wrote:
>
> On Thu, Mar 08, 2018 at 11:19:12PM +1100, Michael Ellerman wrote:
> > Li Wang <[2]liwang@redhat.com> writes:
> > > Hi,
> > >
> > > ltp/mprotect04[1] crashed by SEGV_PKUERR on ppc64(LPAR on P730,
> Power 8
> > > 8247-22L) with kernel-v4.16.0-rc4.
> > >
> > > 10000000-10020000 r-xp 00000000 fd:00 167223 mprotect04
> > > 10020000-10030000 r--p 00010000 fd:00 167223 mprotect04
> > > 10030000-10040000 rw-p 00020000 fd:00 167223 mprotect04
> > > 1001a380000-1001a3b0000 rw-p 00000000 00:00 0 [heap]
> > > 7fffa6c60000-7fffa6c80000 --xp 00000000 00:00 0
> > >
> > > &exec_func = 0x10030170
> > >
> > > &func = 0x7fffa6c60170
> > >
> > > While perform
> > > "(*func)();" we get the
> > > segmentation fault.
> > >
> > >
> > > strace log:
> > >
> > > -------------------
> > > mprotect(0x7fffaed00000, 131072, PROT_EXEC) = 0
> > > rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
> > > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_PKUERR,
> si_addr=0x7fffaed00170}
> > > ---
> >
> > Looks like a bug to me.
> >
> > Please Cc linuxppc-dev on powerpc bugs.
> >
> > I also can't reproduce this failure on my machine.
> > Not sure what's going on?
>
> I could reproduce it on a power7 lpar. But not on a power8 lpar.
>
> The problem seems to be that the cpu generates a key exception if
> the page with Read/Write-disable-but-execute-enable key is executed
> on power7. If I enable read on that key, the exception disappears.
>
> After adding read permission on that key, reproducer get PASS on my power8
> machine too.
> (mprotect(..,PROT_READ | PROT_EXEC))
>
>
> BTW: the testcase executes
> mprotect(..,PROT_EXEC).
> The mprotect(, PROT_EXEC) system call internally generates a
> execute-only key and associates it with the pages in the address-range.
>
> Now since Li Wang claims that he can reproduce it on power8 as well, i
> am wondering if the slightly different cpu behavior is dependent on the
> version of the firmware/microcode?
>
> I also run this reproducer on series ppc kvm machines, but none of them
> get the FAIL.
> If you need some more HW info, pls let me know.
Hi Li,
Can you try the following patch and see if it solves your problem.
diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
index c269817..184a10a 100644
--- a/arch/powerpc/mm/pkeys.c
+++ b/arch/powerpc/mm/pkeys.c
@@ -421,7 +421,7 @@ int __arch_override_mprotect_pkey(struct vm_area_struct *vma, int prot,
* The requested protection is execute-only. Hence let's use an
* execute-only pkey.
*/
- if (prot == PROT_EXEC) {
+ if (prot == PROT_EXEC && pkey_execute_disable_supported) {
pkey = execute_only_pkey(vma->vm_mm);
if (pkey > 0)
return pkey;
Thanks
RP
^ permalink raw reply related
* Re: [PATCH 4/5] powerpc/zImage: Rework serial driver probing
From: Oliver @ 2018-03-20 13:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <87lgenf6ha.fsf@concordia.ellerman.id.au>
On Tue, Mar 20, 2018 at 8:20 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Oliver O'Halloran <oohall@gmail.com> writes:
>
>> Rather than checking the compatible string in serial_driver_init()
>> we call into the driver's init function and wait for a driver to
>> inidicate it bound to the device by returning zero.
>>
>> The pointers to each driver probe functions are stored in the
>> ".serialdrv" section of the zImage, similar to how initcalls and
>> whatnot are handled inside Linux. This structure allows us to
>> conditionally compile specific driver files based on the KConfig
>> settings. This is needed because we don't have access to the
>> KConfig #defines in the zImage source files (it's a giant #include
>> headache) so conditional compilation is the only way to eliminate
>> unnecessary code.
>
> Did you actually get the config.h include working? Or was it such a big
> headache that it doesn't even work?
I had a half-hearted go at it and ran into some problems with include
paths. The usual workaround for that is copying the files into the
build directory and using sed scripts to replace the <> include with a
"" include, so I said screw it and went with this instead. I'm not too
suprised about there being a few linker errors. I tested a few
different defconfigs before posting, but I figured either your CI or
the 0day bot would catch the rest ;)
> I'm pretty happy with this patch regardless, but it would be simpler and
> less bug prone if the CONFIG_ symbols were usable in the boot code.
>
> cheers
^ permalink raw reply
* Re: [PATCH 3/5] powerpc/zImage: Check compatible at driver init
From: Oliver @ 2018-03-20 12:56 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <87o9jjf6jy.fsf@concordia.ellerman.id.au>
On Tue, Mar 20, 2018 at 8:19 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Oliver O'Halloran <oohall@gmail.com> writes:
>> diff --git a/arch/powerpc/boot/mpc52xx-psc.c b/arch/powerpc/boot/mpc52xx-psc.c
>> index c2c08633ee35..75470936e661 100644
>> --- a/arch/powerpc/boot/mpc52xx-psc.c
>> +++ b/arch/powerpc/boot/mpc52xx-psc.c
>> @@ -52,6 +52,9 @@ static unsigned char psc_getc(void)
>>
>> int mpc5200_psc_console_init(void *devp, struct serial_console_data *scdp)
>> {
>> + if (!dt_is_compatible(devp, "fsl,mpc5200-psc-uart"))
>> + return 1;
>
> Returning 1 raises the question of whether this is a bool-style function
> that returns 1 on success and 0 on failure - or a UNIX style function
> that returns 0 for sucesss and 1 on failure.
>
> Can we return ENODEV, or just -1 instead to make it clearer?
I figured we would want to differentiate between a mis-matched driver
and any other error type. There's no existing definition of ENODEV and
friends in the wrapper so I just used positive 1 as a half-assed
workaround. I don't have particularly strong feelings about it so
adding an explicit ENODEV would make things a bit cleaner. I'll fix it
on the respin.
>
> cheers
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/mm: Trace tlbia instruction
From: kbuild test robot @ 2018-03-20 12:32 UTC (permalink / raw)
To: Christophe Leroy
Cc: kbuild-all, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Scott Wood, linux-kernel, linuxppc-dev,
Balbir Singh
In-Reply-To: <cccc5b8516ce8cb57bedf2c51cf67f9a2ca95242.1521452718.git.christophe.leroy@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180320]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc-mm-Add-missing-tracepoint-for-tlbie/20180320-130831
config: powerpc-g5_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
>> arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0x0): multiple definition of `__tracepoint_tlbia'
arch/powerpc/kernel/irq.o:(__tracepoints+0x50): first defined here
arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0x28): multiple definition of `__tracepoint_tlbie'
arch/powerpc/kernel/irq.o:(__tracepoints+0x78): first defined here
arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0x50): multiple definition of `__tracepoint_hash_fault'
arch/powerpc/kernel/irq.o:(__tracepoints+0xa0): first defined here
arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0x78): multiple definition of `__tracepoint_timer_interrupt_exit'
arch/powerpc/kernel/irq.o:(__tracepoints+0xc8): first defined here
arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0xa0): multiple definition of `__tracepoint_timer_interrupt_entry'
arch/powerpc/kernel/irq.o:(__tracepoints+0xf0): first defined here
arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0xc8): multiple definition of `__tracepoint_irq_exit'
arch/powerpc/kernel/irq.o:(__tracepoints+0x28): first defined here
arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0xf0): multiple definition of `__tracepoint_irq_entry'
arch/powerpc/kernel/irq.o:(__tracepoints+0x0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 20798 bytes --]
^ 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-20 11:02 UTC (permalink / raw)
To: Michael Ellerman, Nicholas Piggin
Cc: Anton Blanchard, Benjamin Herrenschmidt, linuxppc-dev,
Paul Mackerras, Steven Rostedt, sathnaga
In-Reply-To: <87r2ofg0e4.fsf@concordia.ellerman.id.au>
Michael Ellerman wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>=20
>> 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.
>>>=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 t=
o
>>> 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.
>>
>> Why not test HSTATE_IN_GUEST then? Add ftrace_disabled if non-KVM users
>> come along.
>=20
> We want to use it for the kexec down path, we've already had bugs there.
I had looked at kexec and we seem to be disabling ftrace in=20
machine_kexec(). Has that been problematic?
I didn't actually realize that you wanted to use this in kexec path as=20
well.
>=20
> So please keep the separate flag and pull it out of #ifdef KVM.
Sure.
- Naveen
=
^ permalink raw reply
* Re: [01/10] selftests/powerpc: add process creation benchmark
From: Michael Ellerman @ 2018-03-20 10:15 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Aneesh Kumar K . V, Nicholas Piggin
In-Reply-To: <20180306132507.10649-2-npiggin@gmail.com>
On Tue, 2018-03-06 at 13:24:58 UTC, Nicholas Piggin wrote:
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/dd40c5b4c90d84d30cdb452c2d193d
cheers
^ permalink raw reply
* Re: powerpc: dts: replace 'linux,stdout-path' with 'stdout-path'
From: Michael Ellerman @ 2018-03-20 10:15 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20180228224406.7049-1-robh@kernel.org>
On Wed, 2018-02-28 at 22:44:06 UTC, Rob Herring wrote:
> 'linux,stdout-path' has been deprecated for some time in favor of
> 'stdout-path'. Now dtc will warn on occurrences of 'linux,stdout-path'.
> Search and replace all the of occurrences with 'stdout-path'.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/78e5dfea84dc15d69940831b3981b3
cheers
^ permalink raw reply
* Re: [3/3] powernv/pci: Improve a size determination in pnv_pci_init_ioda_phb()
From: Michael Ellerman @ 2018-03-20 10:15 UTC (permalink / raw)
To: SF Markus Elfring, linuxppc-dev, Alexey Kardashevskiy,
Alistair Popple, Benjamin Herrenschmidt, David Gibson, Gavin Shan,
Paul Mackerras, Rob Herring, Russell Currey
Cc: kernel-janitors, LKML
In-Reply-To: <03b68902-629e-65ab-a5e8-d90a3613f596@users.sourceforge.net>
On Tue, 2017-10-17 at 15:40:17 UTC, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 17 Oct 2017 17:18:10 +0200
>
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a0828cf57acce9bf941539e1f633e9
cheers
^ permalink raw reply
* Re: [v6, 1/2] raid6/altivec: Add vpermxor implementation for raid6 Q syndrome
From: Michael Ellerman @ 2018-03-20 10:15 UTC (permalink / raw)
To: Matt Brown, linuxppc-dev; +Cc: dja
In-Reply-To: <20170804034233.13628-1-matthew.brown.dev@gmail.com>
On Fri, 2017-08-04 at 03:42:32 UTC, Matt Brown wrote:
> This patch uses the vpermxor instruction to optimise the raid6 Q syndrome.
> This instruction was made available with POWER8, ISA version 2.07.
> It allows for both vperm and vxor instructions to be done in a single
> instruction. This has been tested for correctness on a ppc64le vm with a
> basic RAID6 setup containing 5 drives.
>
> The performance benchmarks are from the raid6test in the /lib/raid6/test
> directory. These results are from an IBM Firestone machine with ppc64le
> architecture. The benchmark results show a 35% speed increase over the best
> existing algorithm for powerpc (altivec). The raid6test has also been run
> on a big-endian ppc64 vm to ensure it also works for big-endian
> architectures.
>
> Performance benchmarks:
> raid6: altivecx4 gen() 18773 MB/s
> raid6: altivecx8 gen() 19438 MB/s
>
> raid6: vpermxor4 gen() 25112 MB/s
> raid6: vpermxor8 gen() 26279 MB/s
>
> Signed-off-by: Matt Brown <matthew.brown.dev@gmail.com>
> Reviewed-by: Daniel Axtens <dja@axtens.net>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/751ba79cc552c146595cd439b21c4f
cheers
^ permalink raw reply
* Re: powerpc/include/asm: Remove unused 64bit cacheflush function
From: Michael Ellerman @ 2018-03-20 10:15 UTC (permalink / raw)
To: Matt Brown, linuxppc-dev
In-Reply-To: <20170720062514.2069-1-matthew.brown.dev@gmail.com>
On Thu, 2017-07-20 at 06:25:14 UTC, Matt Brown wrote:
> The flush_dcache_phys_range function is no longer used in the kernel.
> This patch removes and cleans up the function.
>
> Signed-off-by: Matt Brown <matthew.brown.dev@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/31513207ce72fef5978e8b284e53f2
cheers
^ permalink raw reply
* Re: [PATCH 4/5] powerpc/zImage: Rework serial driver probing
From: Michael Ellerman @ 2018-03-20 9:20 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20180319051403.23275-4-oohall@gmail.com>
Oliver O'Halloran <oohall@gmail.com> writes:
> Rather than checking the compatible string in serial_driver_init()
> we call into the driver's init function and wait for a driver to
> inidicate it bound to the device by returning zero.
>
> The pointers to each driver probe functions are stored in the
> ".serialdrv" section of the zImage, similar to how initcalls and
> whatnot are handled inside Linux. This structure allows us to
> conditionally compile specific driver files based on the KConfig
> settings. This is needed because we don't have access to the
> KConfig #defines in the zImage source files (it's a giant #include
> headache) so conditional compilation is the only way to eliminate
> unnecessary code.
Did you actually get the config.h include working? Or was it such a big
headache that it doesn't even work?
I'm pretty happy with this patch regardless, but it would be simpler and
less bug prone if the CONFIG_ symbols were usable in the boot code.
cheers
^ permalink raw reply
* Re: [PATCH 3/5] powerpc/zImage: Check compatible at driver init
From: Michael Ellerman @ 2018-03-20 9:19 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20180319051403.23275-3-oohall@gmail.com>
Oliver O'Halloran <oohall@gmail.com> writes:
> diff --git a/arch/powerpc/boot/mpc52xx-psc.c b/arch/powerpc/boot/mpc52xx-psc.c
> index c2c08633ee35..75470936e661 100644
> --- a/arch/powerpc/boot/mpc52xx-psc.c
> +++ b/arch/powerpc/boot/mpc52xx-psc.c
> @@ -52,6 +52,9 @@ static unsigned char psc_getc(void)
>
> int mpc5200_psc_console_init(void *devp, struct serial_console_data *scdp)
> {
> + if (!dt_is_compatible(devp, "fsl,mpc5200-psc-uart"))
> + return 1;
Returning 1 raises the question of whether this is a bool-style function
that returns 1 on success and 0 on failure - or a UNIX style function
that returns 0 for sucesss and 1 on failure.
Can we return ENODEV, or just -1 instead to make it clearer?
cheers
^ permalink raw reply
* Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation
From: Ingo Molnar @ 2018-03-20 8:59 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: <20180319232342.GX30522@ZenIV.linux.org.uk>
* Al Viro <viro@ZenIV.linux.org.uk> wrote:
> > 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
>
> ... if you do 32bit build.
Yeah - but the checking tool could do a 32-bit sizing of the types and thus the
checks would work on all arches and on all bitness settings.
I don't think doing part of this in CPP is a good idea:
- It won't be able to do the full range of checks
- Wrappers should IMHO be trivial and open coded as much as possible - not hidden
inside several layers of macros.
- There should be a penalty for newly introduced, badly designed system call
ABIs, while most CPP variants I can think of will just make bad but solvable
decisions palatable, AFAICS.
I.e. I think the way out of this would be two steps:
1) for new system calls: hard-enforce the highest quality at the development
stage and hard-reject crap. No new 6-parameter system calls or badly ordered
arguments. The tool would also check new extensions to existing system calls,
i.e. no more "add a crappy 4th argument to an existing system call that works
on x86 but hurts MIPS".
2) for old legacies: cleanly open code all our existing legacies and weird
wrappers. No new muck will be added to it so the line count does not matter.
... is there anything I'm missing?
Thanks,
Ingo
^ permalink raw reply
* Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation
From: Dominik Brodowski @ 2018-03-20 8:56 UTC (permalink / raw)
To: Al Viro
Cc: Ingo Molnar, Linus Torvalds, 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: <20180319232342.GX30522@ZenIV.linux.org.uk>
On Mon, Mar 19, 2018 at 11:23:42PM +0000, Al Viro wrote:
> static inline long C_S_moron(int, loff_t, size_t);
> long compat_SyS_moron(long a0, long a1, long a2, long a3, long a4, long a5, long a6)
> {
> return C_S_moron((__force int)a0,
> (__force loff_t)(((u64)a2 << 32)|a1),
> (__force size_t)a3);
> }
> static inline long C_S_moron(int fd, loff_t offset, size_t count)
> {
> whatever body you had for it
> }
>
> That - from
> COMPAT_SYSCALL_DEFINE3(moron, int, fd, loff_t, offset, size_t, count)
> {
> whatever body you had for it
> }
>
> We can use similar machinery for SYSCALL_DEFINE itself, so that
> SyS_moron() would be defined with (long, long, long, long, long, long)
> as arguments and not (long, long long, long) as we have now.
That would be great, as it would allow to use a struct pt_regs * based
syscall calling convention on i386 as well, and not only on x86-64, right?
> It's not impossible to do. It won't be pretty, but that use of local
> enums allows to avoid unbearably long expansions.
>
> Benefits:
> * all SyS... wrappers (i.e. the thing that really ought to
> go into syscall tables) have the same type.
> * we could have SYSCALL_DEFINE produce a trivial compat
> wrapper, have explicit COMPAT_SYSCALL_DEFINE discard that thing
> and populate the compat syscall table *entirely* with compat_SyS_...,
> letting the linker sort it out. That way we don't need to keep
> track of what can use native and what needs compat in each compat
> table on biarch.
> * s390 compat wrappers would disappear with that approach.
> * we could even stop generating sys_... aliases - if
> syscall table is generated by slapping SyS_... or compat_SyS_...
> on the name given there, we don't need to _have_ those sys_...
> things at all. All SyS_... would have the same type, so the pile
> in syscalls.h would not be needed - we could generate the externs
> at the same time we generate the syscall table.
>
> And yes, it's a high-squick approach. I know and I'm not saying
> it's a good idea. OTOH, to quote the motto of philosophers and
> shell game operators, "there's something in it"...
... and getting rid of all in-kernel calls to sys_*() is needed as
groundwork for that. So I'll continue to do that "mindless" conversion
first. On top of that, three things (which are mostly orthogonal to each
other) can be done:
1) ptregs system call conversion for x86-64
Original implementation by Linus exists; needs a bit of tweaking
but should be doable soon. Need to double-check it does the right
thing for IA32_EMULATION, though.
2) re-work initramfs etc. code to not use in-kernel equivalents of
syscalls, but operate on the VFS level instead.
3) re-work SYSCALL_DEFINEx() / COMPAT_SYSCALL_DEFINEx() based on
your suggestions.
Does that sound sensible?
Thanks,
Dominik
^ permalink raw reply
* Re: [PATCH v2 8/9] powerpc/eeh: Factor out common code eeh_reset_device()
From: kbuild test robot @ 2018-03-20 8:31 UTC (permalink / raw)
To: Sam Bobroff; +Cc: kbuild-all, linuxppc-dev
In-Reply-To: <557d0231968935f1212c7b500f39363a47cb6acc.1521427331.git.sam.bobroff@au1.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 5661 bytes --]
Hi Sam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180319]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sam-Bobroff/EEH-refactoring-1/20180320-024729
config: powerpc-ppc64_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
Note: the linux-review/Sam-Bobroff/EEH-refactoring-1/20180320-024729 HEAD 28e7cc1fa029b84221b827a6ea2908dc33b43d10 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:14:0,
from include/linux/delay.h:22,
from arch/powerpc/kernel/eeh_driver.c:25:
arch/powerpc/kernel/eeh_driver.c: In function 'eeh_reset_device':
>> arch/powerpc/kernel/eeh_driver.c:692:5: error: 'eeh_aware_driver' undeclared (first use in this function); did you mean 'device_driver'?
(eeh_aware_driver ? "partial" : "complete"));
^
include/linux/printk.h:308:34: note: in definition of macro 'pr_info'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
arch/powerpc/kernel/eeh_driver.c:692:5: note: each undeclared identifier is reported only once for each function it appears in
(eeh_aware_driver ? "partial" : "complete"));
^
include/linux/printk.h:308:34: note: in definition of macro 'pr_info'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
vim +692 arch/powerpc/kernel/eeh_driver.c
619
620 /**
621 * eeh_reset_device - Perform actual reset of a pci slot
622 * @driver_eeh_aware: Does the device's driver provide EEH support?
623 * @pe: EEH PE
624 * @bus: PCI bus corresponding to the isolcated slot
625 * @rmv_data: Optional, list to record removed devices
626 *
627 * This routine must be called to do reset on the indicated PE.
628 * During the reset, udev might be invoked because those affected
629 * PCI devices will be removed and then added.
630 */
631 static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus,
632 struct eeh_rmv_data *rmv_data,
633 bool driver_eeh_aware)
634 {
635 time64_t tstamp;
636 int cnt, rc;
637 struct eeh_dev *edev;
638
639 /* pcibios will clear the counter; save the value */
640 cnt = pe->freeze_count;
641 tstamp = pe->tstamp;
642
643 /*
644 * We don't remove the corresponding PE instances because
645 * we need the information afterwords. The attached EEH
646 * devices are expected to be attached soon when calling
647 * into pci_hp_add_devices().
648 */
649 eeh_pe_state_mark(pe, EEH_PE_KEEP);
650 if (driver_eeh_aware || (pe->type & EEH_PE_VF)) {
651 eeh_pe_dev_traverse(pe, eeh_rmv_device, rmv_data);
652 } else {
653 pci_lock_rescan_remove();
654 pci_hp_remove_devices(bus);
655 pci_unlock_rescan_remove();
656 }
657
658 /*
659 * Reset the pci controller. (Asserts RST#; resets config space).
660 * Reconfigure bridges and devices. Don't try to bring the system
661 * up if the reset failed for some reason.
662 *
663 * During the reset, it's very dangerous to have uncontrolled PCI
664 * config accesses. So we prefer to block them. However, controlled
665 * PCI config accesses initiated from EEH itself are allowed.
666 */
667 rc = eeh_pe_reset_full(pe);
668 if (rc)
669 return rc;
670
671 pci_lock_rescan_remove();
672
673 /* Restore PE */
674 eeh_ops->configure_bridge(pe);
675 eeh_pe_restore_bars(pe);
676
677 /* Clear frozen state */
678 rc = eeh_clear_pe_frozen_state(pe, false);
679 if (rc) {
680 pci_unlock_rescan_remove();
681 return rc;
682 }
683
684 /* Give the system 5 seconds to finish running the user-space
685 * hotplug shutdown scripts, e.g. ifdown for ethernet. Yes,
686 * this is a hack, but if we don't do this, and try to bring
687 * the device up before the scripts have taken it down,
688 * potentially weird things happen.
689 */
690 if (!driver_eeh_aware || rmv_data->removed) {
691 pr_info("EEH: Sleep 5s ahead of %s hotplug\n",
> 692 (eeh_aware_driver ? "partial" : "complete"));
693 ssleep(5);
694
695 /*
696 * The EEH device is still connected with its parent
697 * PE. We should disconnect it so the binding can be
698 * rebuilt when adding PCI devices.
699 */
700 edev = list_first_entry(&pe->edevs, struct eeh_dev, list);
701 eeh_pe_traverse(pe, eeh_pe_detach_dev, NULL);
702 if (pe->type & EEH_PE_VF) {
703 eeh_add_virt_device(edev, NULL);
704 } else {
705 if (!eeh_aware_driver)
706 eeh_pe_state_clear(pe, EEH_PE_PRI_BUS);
707 pci_hp_add_devices(bus);
708 }
709 }
710 eeh_pe_state_clear(pe, EEH_PE_KEEP);
711
712 pe->tstamp = tstamp;
713 pe->freeze_count = cnt;
714
715 pci_unlock_rescan_remove();
716 return 0;
717 }
718
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24150 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] powerpc/zImage: Rework serial driver probing
From: kbuild test robot @ 2018-03-20 8:04 UTC (permalink / raw)
To: Oliver O'Halloran; +Cc: kbuild-all, linuxppc-dev, Oliver O'Halloran
In-Reply-To: <20180319051403.23275-4-oohall@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
Hi Oliver,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180319]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Oliver-O-Halloran/powerpc-zImage-Remove-ifdef-in-opal-c/20180320-023705
config: powerpc-ppc64_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
>> arch/powerpc/boot/wrapper.a(serial.o):(.got2+0x1c): undefined reference to `_serial_drv_start'
>> arch/powerpc/boot/wrapper.a(serial.o):(.got2+0x24): undefined reference to `_serial_drv_end'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24150 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/mm: Add missing tracepoint for tlbie
From: kbuild test robot @ 2018-03-20 8:02 UTC (permalink / raw)
To: Christophe Leroy
Cc: kbuild-all, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Scott Wood, linux-kernel, linuxppc-dev,
Balbir Singh
In-Reply-To: <4ffd3d6143f991615ffe07f43952cbc62163d319.1521452718.git.christophe.leroy@c-s.fr>
[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180319]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc-mm-Add-missing-tracepoint-for-tlbie/20180320-130831
config: powerpc-maple_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
>> arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0x0): multiple definition of `__tracepoint_tlbie'
arch/powerpc/kernel/irq.o:(__tracepoints+0x50): first defined here
>> arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0x28): multiple definition of `__tracepoint_hash_fault'
arch/powerpc/kernel/irq.o:(__tracepoints+0x78): first defined here
>> arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0x50): multiple definition of `__tracepoint_timer_interrupt_exit'
arch/powerpc/kernel/irq.o:(__tracepoints+0xa0): first defined here
>> arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0x78): multiple definition of `__tracepoint_timer_interrupt_entry'
arch/powerpc/kernel/irq.o:(__tracepoints+0xc8): first defined here
>> arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0xa0): multiple definition of `__tracepoint_irq_exit'
arch/powerpc/kernel/irq.o:(__tracepoints+0x28): first defined here
>> arch/powerpc/mm/pgtable-hash64.o:(__tracepoints+0xc8): multiple definition of `__tracepoint_irq_entry'
arch/powerpc/kernel/irq.o:(__tracepoints+0x0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 17658 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/mm: Add missing tracepoint for tlbie
From: Christophe LEROY @ 2018-03-20 7:57 UTC (permalink / raw)
To: Balbir Singh, Kumar Gala
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood, linux-kernel, linuxppc-dev
In-Reply-To: <20180320093940.56144adf@balbir.ozlabs.ibm.com>
Le 19/03/2018 à 23:39, Balbir Singh a écrit :
> On Mon, 19 Mar 2018 11:32:38 +0100 (CET)
> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>> 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);
>
>
> I did not really cover a whole lot of NOHASH, any idea why its
> called tlbil_va and not _tlbie_va?
Seems it comes from
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0ba3418b8b1c85ee1771c63f1dd12041614e56ff
Kumar ?
>
> The first field is really the lpid and should be 0 for non-virtualized
> systems. Can I recommend that we rs field for pid and the rb field for
> address? so effectively something like
Yes having the address in rb is expected since it is the name of the
only field tlbie has in the 32bits instruction set.
Yes I can use rb for the pid.
Christophe
^ permalink raw reply
* Re: [PATCH 4/5] powerpc/zImage: Rework serial driver probing
From: kbuild test robot @ 2018-03-20 7:50 UTC (permalink / raw)
To: Oliver O'Halloran; +Cc: kbuild-all, linuxppc-dev, Oliver O'Halloran
In-Reply-To: <20180319051403.23275-4-oohall@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]
Hi Oliver,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180319]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Oliver-O-Halloran/powerpc-zImage-Remove-ifdef-in-opal-c/20180320-023705
config: powerpc64-alldefconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc64
All errors (new ones prefixed by >>):
arch/powerpc/boot/wrapper.a(crt0.o): In function `_zimage_start_opd':
>> (.text+0x0): multiple definition of `_zimage_start_opd'
arch/powerpc/boot/crt0.o:(.text+0x0): first defined here
arch/powerpc/boot/wrapper.a(crt0.o): In function `_zimage_start':
>> (.text+0x24): multiple definition of `_zimage_start_lib'
arch/powerpc/boot/crt0.o:(.text+0x24): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 8347 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/mm: Trace tlbia instruction
From: Christophe LEROY @ 2018-03-20 7:44 UTC (permalink / raw)
To: Balbir Singh
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood, linux-kernel, linuxppc-dev
In-Reply-To: <20180320094320.03ae264d@balbir.ozlabs.ibm.com>
Le 19/03/2018 à 23:43, Balbir Singh a écrit :
> On Mon, 19 Mar 2018 11:32:40 +0100 (CET)
> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>> 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)
>> +);
>
>
> Do we want to call this lpid?
>
Should we can it rs in consistence with tlbie trace ? Or just pid ?
Allthough it is not an argument used by tlbia, I think it is good to
keep a trace of it to keep track of the reason why tlbia is called.
Christophe
^ permalink raw reply
* Re: [PATCH v2 9/9] powerpc/eeh: Add eeh_state_active() helper
From: kbuild test robot @ 2018-03-20 4:05 UTC (permalink / raw)
To: Sam Bobroff; +Cc: kbuild-all, linuxppc-dev
In-Reply-To: <c7cc2334ac3a7c88cc68b45337de890bcdcc80f7.1521427331.git.sam.bobroff@au1.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 13960 bytes --]
Hi Sam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180319]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sam-Bobroff/EEH-refactoring-1/20180320-024729
config: powerpc-ppc64_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:14:0,
from include/linux/delay.h:22,
from arch/powerpc/kernel/eeh_driver.c:25:
arch/powerpc/kernel/eeh_driver.c: In function 'eeh_reset_device':
>> arch/powerpc/kernel/eeh_driver.c:692:5: error: 'eeh_aware_driver' undeclared (first use in this function); did you mean 'eeh_state_active'?
(eeh_aware_driver ? "partial" : "complete"));
^
include/linux/printk.h:308:34: note: in definition of macro 'pr_info'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
arch/powerpc/kernel/eeh_driver.c:692:5: note: each undeclared identifier is reported only once for each function it appears in
(eeh_aware_driver ? "partial" : "complete"));
^
include/linux/printk.h:308:34: note: in definition of macro 'pr_info'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
vim +692 arch/powerpc/kernel/eeh_driver.c
5cfb20b96 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-09-30 619
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 620 /**
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-02-27 621 * eeh_reset_device - Perform actual reset of a pci slot
a10e51924 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 622 * @driver_eeh_aware: Does the device's driver provide EEH support?
9b3c76f08 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-07 623 * @pe: EEH PE
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-02-27 624 * @bus: PCI bus corresponding to the isolcated slot
a10e51924 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 625 * @rmv_data: Optional, list to record removed devices
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 626 *
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-02-27 627 * This routine must be called to do reset on the indicated PE.
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-02-27 628 * During the reset, udev might be invoked because those affected
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-02-27 629 * PCI devices will be removed and then added.
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 630 */
67086e32b arch/powerpc/kernel/eeh_driver.c Wei Yang 2016-03-04 631 static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus *bus,
a10e51924 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 632 struct eeh_rmv_data *rmv_data,
a10e51924 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 633 bool driver_eeh_aware)
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 634 {
edfd17ff3 arch/powerpc/kernel/eeh_driver.c Arnd Bergmann 2017-11-04 635 time64_t tstamp;
67086e32b arch/powerpc/kernel/eeh_driver.c Wei Yang 2016-03-04 636 int cnt, rc;
67086e32b arch/powerpc/kernel/eeh_driver.c Wei Yang 2016-03-04 637 struct eeh_dev *edev;
424054566 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2006-04-28 638
424054566 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2006-04-28 639 /* pcibios will clear the counter; save the value */
9b3c76f08 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-07 640 cnt = pe->freeze_count;
5a71978e4 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-06-20 641 tstamp = pe->tstamp;
424054566 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2006-04-28 642
20ee6a970 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-11 643 /*
20ee6a970 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-11 644 * We don't remove the corresponding PE instances because
20ee6a970 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-11 645 * we need the information afterwords. The attached EEH
20ee6a970 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-11 646 * devices are expected to be attached soon when calling
bd251b893 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2016-05-03 647 * into pci_hp_add_devices().
20ee6a970 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-11 648 */
807a827d4 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-07-24 649 eeh_pe_state_mark(pe, EEH_PE_KEEP);
e723e4b42 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 650 if (driver_eeh_aware || (pe->type & EEH_PE_VF)) {
e723e4b42 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 651 eeh_pe_dev_traverse(pe, eeh_rmv_device, rmv_data);
67086e32b arch/powerpc/kernel/eeh_driver.c Wei Yang 2016-03-04 652 } else {
1c2042c83 arch/powerpc/kernel/eeh_driver.c Rafael J. Wysocki 2014-01-15 653 pci_lock_rescan_remove();
bd251b893 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2016-05-03 654 pci_hp_remove_devices(bus);
1c2042c83 arch/powerpc/kernel/eeh_driver.c Rafael J. Wysocki 2014-01-15 655 pci_unlock_rescan_remove();
67086e32b arch/powerpc/kernel/eeh_driver.c Wei Yang 2016-03-04 656 }
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 657
d0914f503 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-04-24 658 /*
d0914f503 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-04-24 659 * Reset the pci controller. (Asserts RST#; resets config space).
b6495c0c8 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 660 * Reconfigure bridges and devices. Don't try to bring the system
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-02-27 661 * up if the reset failed for some reason.
d0914f503 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-04-24 662 *
d0914f503 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-04-24 663 * During the reset, it's very dangerous to have uncontrolled PCI
d0914f503 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-04-24 664 * config accesses. So we prefer to block them. However, controlled
d0914f503 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-04-24 665 * PCI config accesses initiated from EEH itself are allowed.
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-02-27 666 */
6654c9368 arch/powerpc/kernel/eeh_driver.c Russell Currey 2016-11-17 667 rc = eeh_pe_reset_full(pe);
28bf36f92 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-11-14 668 if (rc)
b6495c0c8 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 669 return rc;
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 670
1c2042c83 arch/powerpc/kernel/eeh_driver.c Rafael J. Wysocki 2014-01-15 671 pci_lock_rescan_remove();
1c2042c83 arch/powerpc/kernel/eeh_driver.c Rafael J. Wysocki 2014-01-15 672
9b3c76f08 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-07 673 /* Restore PE */
9b3c76f08 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-07 674 eeh_ops->configure_bridge(pe);
9b3c76f08 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-07 675 eeh_pe_restore_bars(pe);
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 676
dc9c41bd9 arch/powerpc/kernel/eeh_driver.c Andrew Donnellan 2015-12-08 677 /* Clear frozen state */
5cfb20b96 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-09-30 678 rc = eeh_clear_pe_frozen_state(pe, false);
409bf7f8a arch/powerpc/kernel/eeh_driver.c Andrew Donnellan 2016-12-01 679 if (rc) {
409bf7f8a arch/powerpc/kernel/eeh_driver.c Andrew Donnellan 2016-12-01 680 pci_unlock_rescan_remove();
789547006 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-04-24 681 return rc;
409bf7f8a arch/powerpc/kernel/eeh_driver.c Andrew Donnellan 2016-12-01 682 }
789547006 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2014-04-24 683
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 684 /* Give the system 5 seconds to finish running the user-space
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 685 * hotplug shutdown scripts, e.g. ifdown for ethernet. Yes,
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 686 * this is a hack, but if we don't do this, and try to bring
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 687 * the device up before the scripts have taken it down,
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 688 * potentially weird things happen.
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 689 */
e723e4b42 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 690 if (!driver_eeh_aware || rmv_data->removed) {
e723e4b42 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 691 pr_info("EEH: Sleep 5s ahead of %s hotplug\n",
e723e4b42 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 @692 (eeh_aware_driver ? "partial" : "complete"));
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 693 ssleep(5);
f5c57710d arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-07-24 694
f5c57710d arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-07-24 695 /*
f5c57710d arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-07-24 696 * The EEH device is still connected with its parent
f5c57710d arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-07-24 697 * PE. We should disconnect it so the binding can be
f5c57710d arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-07-24 698 * rebuilt when adding PCI devices.
f5c57710d arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-07-24 699 */
67086e32b arch/powerpc/kernel/eeh_driver.c Wei Yang 2016-03-04 700 edev = list_first_entry(&pe->edevs, struct eeh_dev, list);
f5c57710d arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-07-24 701 eeh_pe_traverse(pe, eeh_pe_detach_dev, NULL);
a3aa256b7 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2016-06-17 702 if (pe->type & EEH_PE_VF) {
67086e32b arch/powerpc/kernel/eeh_driver.c Wei Yang 2016-03-04 703 eeh_add_virt_device(edev, NULL);
a3aa256b7 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2016-06-17 704 } else {
e723e4b42 arch/powerpc/kernel/eeh_driver.c Sam Bobroff 2018-03-19 705 if (!eeh_aware_driver)
a3aa256b7 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2016-06-17 706 eeh_pe_state_clear(pe, EEH_PE_PRI_BUS);
bd251b893 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2016-05-03 707 pci_hp_add_devices(bus);
a3aa256b7 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2016-06-17 708 }
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 709 }
f5c57710d arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-07-24 710 eeh_pe_state_clear(pe, EEH_PE_KEEP);
5a71978e4 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-06-20 711
5a71978e4 arch/powerpc/kernel/eeh_driver.c Gavin Shan 2013-06-20 712 pe->tstamp = tstamp;
9b3c76f08 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan 2012-09-07 713 pe->freeze_count = cnt;
b6495c0c8 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 714
1c2042c83 arch/powerpc/kernel/eeh_driver.c Rafael J. Wysocki 2014-01-15 715 pci_unlock_rescan_remove();
b6495c0c8 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 716 return 0;
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 717 }
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 718
:::::: The code at line 692 was first introduced by commit
:::::: e723e4b4269eefe9c70fbb6c378a26ab202662e2 powerpc/eeh: Factor out common code eeh_reset_device()
:::::: TO: Sam Bobroff <sam.bobroff@au1.ibm.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24150 bytes --]
^ 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-20 0:05 UTC (permalink / raw)
To: Michael Ellerman
Cc: Naveen N. Rao, Steven Rostedt, Paul Mackerras, linuxppc-dev,
Benjamin Herrenschmidt, Anton Blanchard, sathnaga
In-Reply-To: <87r2ofg0e4.fsf@concordia.ellerman.id.au>
On Tue, 20 Mar 2018 09:34:43 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
> > 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.
>
> We want to use it for the kexec down path, we've already had bugs there.
>
> So please keep the separate flag and pull it out of #ifdef KVM.
Okay that's fine.
> If we're worried about space usage in the paca we can probably
> consolidate this and some other things into a flags word.
I'm not too concerned about some more u8 flags.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h
From: Oliver @ 2018-03-19 23:55 UTC (permalink / raw)
To: Mark Greer
Cc: Christophe LEROY, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, linuxppc-dev, David Gibson
In-Reply-To: <20180319160216.GD9670@animalcreek.com>
On Tue, Mar 20, 2018 at 3:02 AM, Mark Greer <mgreer@animalcreek.com> wrote:
> On Mon, Mar 19, 2018 at 09:53:09AM +0100, Christophe LEROY wrote:
>>
>>
>> Le 16/03/2018 =C3=A0 22:54, Mark Greer a =C3=A9crit :
>> >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 type=
def 'uint32_t'
>> > ../arch/powerpc/boot/types.h:21:13: note: previous declaration of 'u=
int32_t' was here
>> > ../arch/powerpc/boot/libfdt_env.h:11:13: error: redefinition of type=
def 'uint64_t'
>> > ../arch/powerpc/boot/types.h:22:13: note: previous declaration of 'u=
int64_t' was here
>> > ../arch/powerpc/boot/Makefile:210: recipe for target 'arch/powerpc/b=
oot/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 bu=
t
>> >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 see=
ms
>> 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.
Yeah that's pretty odd. It might be a bug in your specific version of
GCC since I can't replicate it with this dumb test case:
#include <stdio.h>
typedef unsigned int u32;
typedef u32 uint32_t;
typedef u32 uint32_t;
int main(void) {
uint32_t test =3D 0;
printf("%u\n", test);
return 0;
}
Does that result in an error?
> Either way, it seems to me that we should remove the duplicate definition=
s.
> Do you agree?
It wouldn't hurt to remove those definitions from libfdt_env.h. That
file includes types.h directly anyway so there's not much point in
them being there.
Thanks,
Oliver
^ permalink raw reply
* Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation
From: Al Viro @ 2018-03-19 23:23 UTC (permalink / raw)
To: Ingo Molnar
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: <20180319092920.tbh2xwkruegshzqe@gmail.com>
On Mon, Mar 19, 2018 at 10:29:20AM +0100, Ingo Molnar wrote:
>
> * 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/!
If you want to turn that into something printable - more power to you...
FWIW, I think we need to require per-architecture descriptions of ABI
for all architectures. Something along the lines of
alpha:
C ABI: 64bit, location sequence is ($16, $17, $18, $19, $20, $21, stack)
No arg padding (as for all 64bit). Stack pointer in $30, return value
in $0.
Syscall ABI: syscall number in $0, arg slots filled from $16, $17, $18, $19,
$20, $21. Return value in $0, error is reported as 1 in $19. Saved
syscall number is used as a flag for __force_successful_syscall_return()
purposes - sticking 0 there inhibits the effect of negative return value.
arm:
C ABI: 32bit, location sequence is (r0, r1, r2, r3, stack). Arg padding
for 64bit args: to even slot. Stack pointer in sp, return value in r0
Syscall ABI, EABI variant: syscall number in r7.
Syscall ABI, OABI variant: syscall number encoded into insn.
Syscall ABI (both variants): arg slots filled from r0, r1, r2, r3, r4, r5.
Return value in r0. It's not quite a biarch (support of e.g. ioctl
handling is absent, etc.; basic syscalls are handled, but that's it).
etc. Ideally the information about callee-saved registers, syscall restart
logics, etc. should also go there. I'm sick and tired of digging though
the asm glue of unfamiliar architectures ;-/
Another relevant piece of information (especially for biarch) is how
should sub-word arguments be normalized. E.g. on amd64 both int and long
are passed in 64bit words and function that expects an int does *not*
care about the upper 32 bits. If you have long f(int a) {return a;},
it will sign-extend the argument. On ppc, OTOH, it won't - the caller
is responsible for having the bits 31..63 all equal.
That used to be a source of considerable PITA - e.g. kill(2) used to
require a compat wrapper on ppc. These days SYSCALL_DEFINE and
COMPAT_SYSCALL_DEFINE glue takes care of normalizations. However
it doesn't apply for the stuff that does *not* use ...DEFINE and
for use of native syscalls on biarch we need a bit more. Consider
e.g. 32bit syscall on sparc64 wanting to use the native counterpart.
Arguments that are <= 32bit in both ABIs are fine - normalizations
will take care of them. Anything that is 64bit in both ABIs means
that we will need compat anyway - the argument needs to be recombined
from two registers into one. The headache comes from
* signed long
* unsigned long
* pointers
Those are word-sized and we need to normalize. Solution before
SYSCALL_DEFINE glue: have upper halves forcibly zeroed on entry (which
normalizes unsigned long and pointers) and then sign-extend every
signed int and signed long in per-syscall glue (that zeroing is
guaranteed to denormalize int arguments). Once SYSCALL_DEFINE started
to do normalization we disposed on the need to do separate wrappers
for int arguments; that still leaves us with signed long ones, but
* they are very rare
* most of the syscalls passing them need compat for more
serious reasons anyway.
There are only two exceptions - bdflush(2) and pciconfig_iobase(2).
The latter doesn't exist on sparc, the former ignores its signed long
argument completely. So we are left with "zero upper halves of all
argument-bearing registers upon the entry and have per-syscall glue
take care of the rest".
For s390 the situation is nastier - normalization for signed and
unsigned long is the same as usual, but pointers might have junk
in bit 31. IOW, for anything with pointer in arguments we can't
just use the native syscall. As the result, s390 doesn't bother
with zeroing upper halves in syscall dispatcher and does private
mini-wrappers for native syscalls with pointer/long/ulong arguments.
That kind of crap really needs to be documented - RTFS becomes
somewhat painful when it involves tens of assemblers *and*
missing ABI documents (try to locate one for something embedded -
great motivation for expanding vocabulary, that) ;-/
FWIW, SYSCALL_DEFINE and its ilk (COMPAT_SYSCALL_DEFINE,
s390 COMPAT_SYSCALL_WRAP, etc.) are all about stepping over the
ABI gap - we've got some values from userland caller and we
need to turn that into a valid C function call that would
satisfy C ABI constraints. Some amount of normalization might've
been done by syscall dispatcher; this stuff does the rest on
per-function basis.
> 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.
Umm... Possible, but I actually believe that we can do that without
debug info.
WARNING: AVERT YOUR EYES IF YOU HAVE A WEAK STOMACH. I'm _not_ saying that
the trickery below is a good idea, no need to break out a straightjacket.
It does have some merits, but in the current form it's ugly as hell and
almost certainly not fit for inclusion. Consider that as a theoretical
exercise, please.
Again, don't read further if you are easily squicked. You've been warned.
===============================================================================
Look:
* we can generate
enum {S0 = __TYPE_IS_LL(int),
S1 = __TYPE_IS_LL(loff_t),
S2 = __TYPE_IS_LL(size_t)};
at preprocessor level (inside the compat wrapper being built). Calculations
will be done at compile time, of course, but those _are_ constants (0, 1, 0 in
our case).
* we can generate
enum {OFF0 = 0, OFF1 = STEP(OFF0 + S0, S1), OFF2 = STEP(OFF1 + S1, S2)};
at the same time, with STEP(base, big) defined as base + 1 for something like
x86, (big ? ((base) | 1) + 1 : (base) + 1) for arm and friends,
base + 1 + (big && base == 3) for s390. Again, compile-time calculations.
For x86 - (0, 1, 3), for arm - (0, 2, 4), etc.
* we can generate
C_S_moron((__force int)(S0 ? PAIR(OFF0) : ARG(OFF0)),
(__force loff_t)(S1 ? PAIR(OFF1) : ARG(OFF1)),
(__force size_t)(S2 ? PAIR(OFF2) : ARG(OFF2)));
in the body of wrapper. With PAIR(n) defined as either ((u64)ARG(n) << 32) | ARG(n+1)
or ((u64)ARG(n+1) << 32) | ARG(n) (depending upon endianness) and ARG(n)
defined as (n == 0 ? a0 : n == 1 ? a1 : n == 2 ? a2 : n == 3 ? a3 :
n == 4 ? a4 : n == 5 ? a5 : a6)
Note that each of those suckers expands to a cascade of conditional
expressions with all conditions being integer constant expressions,
no more than one of those being true. In our case that crap will fold into
C_S_moron((__force int)a0,
(__force loff_t)(((u64)a2 << 32)|a1),
(__force size_t)a3);
as soon as optimizations at the level of 0 ? x : y => y and 1 ? x : y => x
are done. And we have, in effect,
static inline long C_S_moron(int, loff_t, size_t);
long compat_SyS_moron(long a0, long a1, long a2, long a3, long a4, long a5, long a6)
{
return C_S_moron((__force int)a0,
(__force loff_t)(((u64)a2 << 32)|a1),
(__force size_t)a3);
}
static inline long C_S_moron(int fd, loff_t offset, size_t count)
{
whatever body you had for it
}
That - from
COMPAT_SYSCALL_DEFINE3(moron, int, fd, loff_t, offset, size_t, count)
{
whatever body you had for it
}
We can use similar machinery for SYSCALL_DEFINE itself, so that
SyS_moron() would be defined with (long, long, long, long, long, long)
as arguments and not (long, long long, long) as we have now.
It's not impossible to do. It won't be pretty, but that use of local
enums allows to avoid unbearably long expansions.
Benefits:
* all SyS... wrappers (i.e. the thing that really ought to
go into syscall tables) have the same type.
* we could have SYSCALL_DEFINE produce a trivial compat
wrapper, have explicit COMPAT_SYSCALL_DEFINE discard that thing
and populate the compat syscall table *entirely* with compat_SyS_...,
letting the linker sort it out. That way we don't need to keep
track of what can use native and what needs compat in each compat
table on biarch.
* s390 compat wrappers would disappear with that approach.
* we could even stop generating sys_... aliases - if
syscall table is generated by slapping SyS_... or compat_SyS_...
on the name given there, we don't need to _have_ those sys_...
things at all. All SyS_... would have the same type, so the pile
in syscalls.h would not be needed - we could generate the externs
at the same time we generate the syscall table.
And yes, it's a high-squick approach. I know and I'm not saying
it's a good idea. OTOH, to quote the motto of philosophers and
shell game operators, "there's something in it"...
> 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
... if you do 32bit build.
> 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)
> 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
Uhhuh - ABI-safe is not how I would describe that. Sodding PITA, fortunately
rare, is more like it...
> 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).
See above. It *can* be done. Not by cpp alone, of course - you need compiler
involvement.
^ 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