* Re: [PATCH v2 4/4] mm/vmalloc: Hugepage vmalloc mappings
From: Nicholas Piggin @ 2020-04-16 2:38 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, Catalin Marinas, x86, linux-kernel, linux-mm,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Thomas Gleixner,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200415104755.GD12621@willie-the-truck>
Excerpts from Will Deacon's message of April 15, 2020 8:47 pm:
> Hi Nick,
>
> On Mon, Apr 13, 2020 at 10:53:03PM +1000, Nicholas Piggin wrote:
>> For platforms that define HAVE_ARCH_HUGE_VMAP and support PMD vmap mappings,
>> have vmalloc attempt to allocate PMD-sized pages first, before falling back
>> to small pages. Allocations which use something other than PAGE_KERNEL
>> protections are not permitted to use huge pages yet, not all callers expect
>> this (e.g., module allocations vs strict module rwx).
>>
>> This gives a 6x reduction in dTLB misses for a `git diff` (of linux), from
>> 45600 to 6500 and a 2.2% reduction in cycles on a 2-node POWER9.
>
> I wonder if it's worth extending vmap() to handle higher order pages in
> a similar way? That might be helpful for tracing PMUs such as Arm SPE,
> where the CPU streams tracing data out to a virtually addressed buffer
> (see rb_alloc_aux_page()).
Yeah it becomes pretty trivial to do that with VM_HUGE_PAGES after
this patch, I have something to do it but no callers ready yet, if
you have an easy one we can add it.
>> This can result in more internal fragmentation and memory overhead for a
>> given allocation. It can also cause greater NUMA unbalance on hashdist
>> allocations.
>>
>> There may be other callers that expect small pages under vmalloc but use
>> PAGE_KERNEL, I'm not sure if it's feasible to catch them all. An
>> alternative would be a new function or flag which enables large mappings,
>> and use that in callers.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> include/linux/vmalloc.h | 2 +
>> mm/vmalloc.c | 135 +++++++++++++++++++++++++++++-----------
>> 2 files changed, 102 insertions(+), 35 deletions(-)
>>
>> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
>> index 291313a7e663..853b82eac192 100644
>> --- a/include/linux/vmalloc.h
>> +++ b/include/linux/vmalloc.h
>> @@ -24,6 +24,7 @@ struct notifier_block; /* in notifier.h */
>> #define VM_UNINITIALIZED 0x00000020 /* vm_struct is not fully initialized */
>> #define VM_NO_GUARD 0x00000040 /* don't add guard page */
>> #define VM_KASAN 0x00000080 /* has allocated kasan shadow memory */
>> +#define VM_HUGE_PAGES 0x00000100 /* may use huge pages */
>
> Please can you add a check for this in the arm64 change_memory_common()
> code? Other architectures might need something similar, but we need to
> forbid changing memory attributes for portions of the huge page.
Yeah good idea, I can look about adding some more checks.
>
> In general, I'm a bit wary of software table walkers tripping over this.
> For example, I don't think apply_to_existing_page_range() can handle
> huge mappings at all, but the one user (KASAN) only ever uses page mappings
> so it's ok there.
Right, I have something to warn for apply to page range (and looking
at adding support for bigger pages). It doesn't even have a test and
warn at the moment which isn't good practice IMO so we should add one
even without huge vmap.
>
>> @@ -2325,9 +2356,11 @@ static struct vm_struct *__get_vm_area_node(unsigned long size,
>> if (unlikely(!size))
>> return NULL;
>>
>> - if (flags & VM_IOREMAP)
>> - align = 1ul << clamp_t(int, get_count_order_long(size),
>> - PAGE_SHIFT, IOREMAP_MAX_ORDER);
>> + if (flags & VM_IOREMAP) {
>> + align = max(align,
>> + 1ul << clamp_t(int, get_count_order_long(size),
>> + PAGE_SHIFT, IOREMAP_MAX_ORDER));
>> + }
>
>
> I don't follow this part. Please could you explain why you're potentially
> aligning above IOREMAP_MAX_ORDER? It doesn't seem to follow from the rest
> of the patch.
Trying to remember. If the caller asks for a particular alignment we
shouldn't reduce it. Should put it in another patch.
Thanks,
Nick
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 2:35 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <1587002854.f0slo0111r.astroid@bobo.none>
On Thu, Apr 16, 2020 at 12:24:16PM +1000, Nicholas Piggin wrote:
> >> > Likewise, it's not useful to have different error return mechanisms
> >> > because the caller just has to branch to support both (or the
> >> > kernel-provided stub just has to emulate one for it; that could work
> >> > if you really want to change the bad existing convention).
> >> >
> >> > Thoughts?
> >>
> >> The existing convention has to change somewhat because of the clobbers,
> >> so I thought we could change the error return at the same time. I'm
> >> open to not changing it and using CR0[SO], but others liked the idea.
> >> Pro: it matches sc and vsyscall. Con: it's different from other common
> >> archs. Performnce-wise it would really be a wash -- cost of conditional
> >> branch is not the cmp but the mispredict.
> >
> > If you do the branch on hwcap at each syscall, then you significantly
> > increase code size of every syscall point, likely turning a bunch of
> > trivial functions that didn't need stack frames into ones that do. You
> > also potentially make them need a TOC pointer. Making them all just do
> > an indirect call unconditionally (with pointer in TLS like i386?) is a
> > lot more efficient in code size and at least as good for performance.
>
> I disagree. Doing the long vdso indirect call *necessarily* requires
> touching a new icache line, and even a new TLB entry. Indirect branches
The increase in number of icache lines from the branch at every
syscall point is far greater than the use of a single extra icache
line shared by all syscalls. Not to mention the dcache line to access
__hwcap or whatever, and the icache lines to setup access TOC-relative
access to it. (Of course you could put a copy of its value in TLS at a
fixed offset, which would somewhat mitigate both.)
> And finally, the HWCAP test can eventually go away in future. A vdso
> call can not.
We support nearly arbitrarily old kernels (with limited functionality)
and hardware (with full functionality) and don't intend for that to
change, ever. But indeed glibc might want too eventually drop the
check.
> If you really want to select with an indirect branch rather than
> direct conditional, you can do that all within the library.
OK. It's a little bit more work if that's not the interface the kernel
will give us, but it's no big deal.
Rich
^ permalink raw reply
* Re: [PATCH kernel v2 0/7] powerpc/powenv/ioda: Allow huge DMA window at 4GB
From: Oliver O'Halloran @ 2020-04-16 2:34 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: KVM list, Fabiano Rosas, Alistair Popple, kvm-ppc, linuxppc-dev,
David Gibson
In-Reply-To: <d5cac37a-8b32-cabf-e247-10e64f0110ab@ozlabs.ru>
On Thu, Apr 16, 2020 at 11:27 AM Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
> Anyone? Is it totally useless or wrong approach? Thanks,
I wouldn't say it's either, but I still hate it.
The 4GB mode being per-PHB makes it difficult to use unless we force
that mode on 100% of the time which I'd prefer not to do. Ideally
devices that actually support 64bit addressing (which is most of them)
should be able to use no-translate mode when possible since a) It's
faster, and b) It frees up room in the TCE cache devices that actually
need them. I know you've done some testing with 100G NICs and found
the overhead was fine, but IMO that's a bad test since it's pretty
much the best-case scenario since all the devices on the PHB are in
the same PE. The PHB's TCE cache only hits when the TCE matches the
DMA bus address and the PE number for the device so in a multi-PE
environment there's a lot of potential for TCE cache trashing. If
there was one or two PEs under that PHB it's probably not going to
matter, but if you have an NVMe rack with 20 drives it starts to look
a bit ugly.
That all said, it might be worth doing this anyway since we probably
want the software infrastructure in place to take advantage of it.
Maybe expand the command line parameters to allow it to be enabled on
a per-PHB basis rather than globally.
Oliver
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Nicholas Piggin @ 2020-04-16 2:24 UTC (permalink / raw)
To: Rich Felker; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <20200416004843.GO11469@brightrain.aerifal.cx>
Excerpts from Rich Felker's message of April 16, 2020 10:48 am:
> On Thu, Apr 16, 2020 at 10:16:54AM +1000, Nicholas Piggin wrote:
>> Excerpts from Rich Felker's message of April 16, 2020 8:55 am:
>> > On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote:
>> >> I would like to enable Linux support for the powerpc 'scv' instruction,
>> >> as a faster system call instruction.
>> >>
>> >> This requires two things to be defined: Firstly a way to advertise to
>> >> userspace that kernel supports scv, and a way to allocate and advertise
>> >> support for individual scv vectors. Secondly, a calling convention ABI
>> >> for this new instruction.
>> >>
>> >> Thanks to those who commented last time, since then I have removed my
>> >> answered questions and unpopular alternatives but you can find them
>> >> here
>> >>
>> >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
>> >>
>> >> Let me try one more with a wider cc list, and then we'll get something
>> >> merged. Any questions or counter-opinions are welcome.
>> >>
>> >> System Call Vectored (scv) ABI
>> >> ==============================
>> >>
>> >> The scv instruction is introduced with POWER9 / ISA3, it comes with an
>> >> rfscv counter-part. The benefit of these instructions is performance
>> >> (trading slower SRR0/1 with faster LR/CTR registers, and entering the
>> >> kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
>> >> updates. The scv instruction has 128 interrupt entry points (not enough
>> >> to cover the Linux system call space).
>> >>
>> >> The proposal is to assign scv numbers very conservatively and allocate
>> >> them as individual HWCAP features as we add support for more. The zero
>> >> vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
>> >>
>> >> Advertisement
>> >>
>> >> Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
>> >> SIGILL in current environments. Linux has defined a HWCAP2 bit
>> >> PPC_FEATURE2_SCV for SCV support, but does not set it.
>> >>
>> >> When scv instruction support and the scv 0 vector for system calls are
>> >> added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
>> >> should not be used without future HWCAP bits indicating support, which is
>> >> how we will allocate them. (Should unallocated ones generate SIGILL, or
>> >> return -ENOSYS in r3?)
>> >>
>> >> Calling convention
>> >>
>> >> The proposal is for scv 0 to provide the standard Linux system call ABI
>> >> with the following differences from sc convention[1]:
>> >>
>> >> - LR is to be volatile across scv calls. This is necessary because the
>> >> scv instruction clobbers LR. From previous discussion, this should be
>> >> possible to deal with in GCC clobbers and CFI.
>> >>
>> >> - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
>> >> kernel system call exit to avoid restoring the CR register (although
>> >> we probably still would anyway to avoid information leak).
>> >>
>> >> - Error handling: I think the consensus has been to move to using negative
>> >> return value in r3 rather than CR0[SO]=1 to indicate error, which matches
>> >> most other architectures and is closer to a function call.
>> >>
>> >> The number of scratch registers (r9-r12) at kernel entry seems
>> >> sufficient that we don't have any costly spilling, patch is here[2].
>> >>
>> >> [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
>> >> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840..html
>> >
>> > My preference would be that it work just like the i386 AT_SYSINFO
>> > where you just replace "int $128" with "call *%%gs:16" and the kernel
>> > provides a stub in the vdso that performs either scv or the old
>> > mechanism with the same calling convention. Then if the kernel doesn't
>> > provide it (because the kernel is too old) libc would have to provide
>> > its own stub that uses the legacy method and matches the calling
>> > convention of the one the kernel is expected to provide.
>>
>> I'm not sure if that's necessary. That's done on x86-32 because they
>> select different sequences to use based on the CPU running and if the host
>> kernel is 32 or 64 bit. Sure they could in theory have a bunch of HWCAP
>> bits and select the right sequence in libc as well I suppose.
>
> It's not just a HWCAP. It's a contract between the kernel and
> userspace to support a particular calling convention that's not
> exposed except as the public entry point the kernel exports via
> AT_SYSINFO.
Right.
>> > Note that any libc that actually makes use of the new functionality is
>> > not going to be able to make clobbers conditional on support for it;
>> > branching around different clobbers is going to defeat any gains vs
>> > always just treating anything clobbered by either method as clobbered.
>>
>> Well it would have to test HWCAP and patch in or branch to two
>> completely different sequences including register save/restores yes.
>> You could have the same asm and matching clobbers to put the sequence
>> inline and then you could patch the one sc/scv instruction I suppose.
>>
>> A bit of logic to select between them doesn't defeat gains though,
>> it's about 90 cycle improvement which is a handful of branch mispredicts
>> so it really is an improvement. Eventually userspace will stop
>> supporting the old variant too.
>
> Oh, I didn't mean it would neutralize the benefit of svc. Rather, I
> meant it would be worse to do:
>
> if (hwcap & X) {
> __asm__(... with some clobbers);
> } else {
> __asm__(... with different clobbers);
> }
>
> instead of just
>
> __asm__("indirect call" ... with common clobbers);
Ah okay. Well that's debatable but if you didn't have an indirect call,
rather a runtime-patched sequence, then yes saving the LR clobber or
whatever wouldn't be worth a branch.
> where the indirect call is to an address ideally provided like on
> i386, or otherwise initialized to one of two or more code addresses in
> libc based on hwcap bits.
Right, I'm just skeptical we need the indirect call or need to provide
it in the vdso. The "clever" reason to add it on x86-32 was because of
the bugs and different combinations needed, that doesn't really apply
to scv 0 and was not necessarily a great choice.
>
>> > Likewise, it's not useful to have different error return mechanisms
>> > because the caller just has to branch to support both (or the
>> > kernel-provided stub just has to emulate one for it; that could work
>> > if you really want to change the bad existing convention).
>> >
>> > Thoughts?
>>
>> The existing convention has to change somewhat because of the clobbers,
>> so I thought we could change the error return at the same time. I'm
>> open to not changing it and using CR0[SO], but others liked the idea.
>> Pro: it matches sc and vsyscall. Con: it's different from other common
>> archs. Performnce-wise it would really be a wash -- cost of conditional
>> branch is not the cmp but the mispredict.
>
> If you do the branch on hwcap at each syscall, then you significantly
> increase code size of every syscall point, likely turning a bunch of
> trivial functions that didn't need stack frames into ones that do. You
> also potentially make them need a TOC pointer. Making them all just do
> an indirect call unconditionally (with pointer in TLS like i386?) is a
> lot more efficient in code size and at least as good for performance.
I disagree. Doing the long vdso indirect call *necessarily* requires
touching a new icache line, and even a new TLB entry. Indirect branches
also tend to be more costly and/or less accurate to predict than
direct even without spectre (generally fewer indirect predictor entries
than direct, far branches in particular require a lot of bits for
target). And with spectre we're flushing the indirect predictors
on context switch or even disabling indirect prediction or flushing
across privilege domains in the same context.
And finally, the HWCAP test can eventually go away in future. A vdso
call can not.
If you really want to select with an indirect branch rather than
direct conditional, you can do that all within the library.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH 01/34] docs: filesystems: fix references for doc files there
From: Joseph Qi @ 2020-04-16 1:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Jan Kara, Rafael J. Wysocki, David Airlie, Amir Goldstein,
dri-devel, linux-unionfs, David Howells, Harry Wei,
Paul Mackerras, Mikulas Patocka, Alex Shi, linux-afs,
Jonathan Corbet, Mark Fasheh, Tyler Hicks, Christoph Hellwig,
Anton Altaparmakov, Federico Vaga, Alexey Dobriyan, freedreno,
linux-arm-msm, ecryptfs, Alexander Viro, Tigran A. Aivazian,
David Sterba, Sean Paul, OGAWA Hirofumi, Nicolas Pitre,
linux-ntfs-dev, Greg Kroah-Hartman, Miklos Szeredi, linux-kernel,
Rob Clark, Daniel Vetter, linux-fsdevel, linuxppc-dev,
ocfs2-devel, Joel Becker
In-Reply-To: <4233bc0ed8d3ebd45da248332c157a9e04a16058.1586960617.git.mchehab+huawei@kernel.org>
On 2020/4/15 22:32, Mauro Carvalho Chehab wrote:
> Several files there were renamed to ReST. Fix the broken
> references.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
> Documentation/ABI/stable/sysfs-devices-node | 2 +-
> Documentation/ABI/testing/procfs-smaps_rollup | 2 +-
> Documentation/admin-guide/cpu-load.rst | 2 +-
> Documentation/admin-guide/nfs/nfsroot.rst | 2 +-
> Documentation/driver-api/driver-model/device.rst | 2 +-
> Documentation/driver-api/driver-model/overview.rst | 2 +-
> Documentation/filesystems/dax.txt | 2 +-
> Documentation/filesystems/dnotify.txt | 2 +-
> Documentation/filesystems/ramfs-rootfs-initramfs.rst | 2 +-
> Documentation/powerpc/firmware-assisted-dump.rst | 2 +-
> Documentation/process/adding-syscalls.rst | 2 +-
> .../translations/it_IT/process/adding-syscalls.rst | 2 +-
> Documentation/translations/zh_CN/filesystems/sysfs.txt | 6 +++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +-
> fs/Kconfig | 2 +-
> fs/Kconfig.binfmt | 2 +-
> fs/adfs/Kconfig | 2 +-
> fs/affs/Kconfig | 2 +-
> fs/afs/Kconfig | 6 +++---
> fs/bfs/Kconfig | 2 +-
> fs/cramfs/Kconfig | 2 +-
> fs/ecryptfs/Kconfig | 2 +-
> fs/fat/Kconfig | 8 ++++----
> fs/fuse/Kconfig | 2 +-
> fs/fuse/dev.c | 2 +-
> fs/hfs/Kconfig | 2 +-
> fs/hpfs/Kconfig | 2 +-
> fs/isofs/Kconfig | 2 +-
> fs/namespace.c | 2 +-
> fs/notify/inotify/Kconfig | 2 +-
> fs/ntfs/Kconfig | 2 +-
> fs/ocfs2/Kconfig | 2 +-
For ocfs2 part,
Acked-by: Joseph Qi <joseph.qi@linux.alibaba.com>
> fs/overlayfs/Kconfig | 6 +++---
> fs/proc/Kconfig | 4 ++--
> fs/romfs/Kconfig | 2 +-
> fs/sysfs/dir.c | 2 +-
> fs/sysfs/file.c | 2 +-
> fs/sysfs/mount.c | 2 +-
> fs/sysfs/symlink.c | 2 +-
> fs/sysv/Kconfig | 2 +-
> fs/udf/Kconfig | 2 +-
> include/linux/relay.h | 2 +-
> include/linux/sysfs.h | 2 +-
> kernel/relay.c | 2 +-
> 44 files changed, 54 insertions(+), 54 deletions(-)
>
> diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node
> index df8413cf1468..484fc04bcc25 100644
> --- a/Documentation/ABI/stable/sysfs-devices-node
> +++ b/Documentation/ABI/stable/sysfs-devices-node
> @@ -54,7 +54,7 @@ Date: October 2002
> Contact: Linux Memory Management list <linux-mm@kvack.org>
> Description:
> Provides information about the node's distribution and memory
> - utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt
> + utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.rst
>
> What: /sys/devices/system/node/nodeX/numastat
> Date: October 2002
> diff --git a/Documentation/ABI/testing/procfs-smaps_rollup b/Documentation/ABI/testing/procfs-smaps_rollup
> index 274df44d8b1b..046978193368 100644
> --- a/Documentation/ABI/testing/procfs-smaps_rollup
> +++ b/Documentation/ABI/testing/procfs-smaps_rollup
> @@ -11,7 +11,7 @@ Description:
> Additionally, the fields Pss_Anon, Pss_File and Pss_Shmem
> are not present in /proc/pid/smaps. These fields represent
> the sum of the Pss field of each type (anon, file, shmem).
> - For more details, see Documentation/filesystems/proc.txt
> + For more details, see Documentation/filesystems/proc.rst
> and the procfs man page.
>
> Typical output looks like this:
> diff --git a/Documentation/admin-guide/cpu-load.rst b/Documentation/admin-guide/cpu-load.rst
> index 2d01ce43d2a2..ebdecf864080 100644
> --- a/Documentation/admin-guide/cpu-load.rst
> +++ b/Documentation/admin-guide/cpu-load.rst
> @@ -105,7 +105,7 @@ References
> ----------
>
> - http://lkml.org/lkml/2007/2/12/6
> -- Documentation/filesystems/proc.txt (1.8)
> +- Documentation/filesystems/proc.rst (1.8)
>
>
> Thanks
> diff --git a/Documentation/admin-guide/nfs/nfsroot.rst b/Documentation/admin-guide/nfs/nfsroot.rst
> index 82a4fda057f9..c6772075c80c 100644
> --- a/Documentation/admin-guide/nfs/nfsroot.rst
> +++ b/Documentation/admin-guide/nfs/nfsroot.rst
> @@ -18,7 +18,7 @@ Mounting the root filesystem via NFS (nfsroot)
> In order to use a diskless system, such as an X-terminal or printer server for
> example, it is necessary for the root filesystem to be present on a non-disk
> device. This may be an initramfs (see
> -Documentation/filesystems/ramfs-rootfs-initramfs.txt), a ramdisk (see
> +Documentation/filesystems/ramfs-rootfs-initramfs.rst), a ramdisk (see
> Documentation/admin-guide/initrd.rst) or a filesystem mounted via NFS. The
> following text describes on how to use NFS for the root filesystem. For the rest
> of this text 'client' means the diskless system, and 'server' means the NFS
> diff --git a/Documentation/driver-api/driver-model/device.rst b/Documentation/driver-api/driver-model/device.rst
> index 2b868d49d349..b8c15a39a9a0 100644
> --- a/Documentation/driver-api/driver-model/device.rst
> +++ b/Documentation/driver-api/driver-model/device.rst
> @@ -50,7 +50,7 @@ Attributes
>
> Attributes of devices can be exported by a device driver through sysfs.
>
> -Please see Documentation/filesystems/sysfs.txt for more information
> +Please see Documentation/filesystems/sysfs.rst for more information
> on how sysfs works.
>
> As explained in Documentation/kobject.txt, device attributes must be
> diff --git a/Documentation/driver-api/driver-model/overview.rst b/Documentation/driver-api/driver-model/overview.rst
> index d4d1e9b40e0c..e98d0ab4a9b6 100644
> --- a/Documentation/driver-api/driver-model/overview.rst
> +++ b/Documentation/driver-api/driver-model/overview.rst
> @@ -121,4 +121,4 @@ device-specific data or tunable interfaces.
>
> More information about the sysfs directory layout can be found in
> the other documents in this directory and in the file
> -Documentation/filesystems/sysfs.txt.
> +Documentation/filesystems/sysfs.rst.
> diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt
> index 679729442fd2..735f3859b19f 100644
> --- a/Documentation/filesystems/dax.txt
> +++ b/Documentation/filesystems/dax.txt
> @@ -74,7 +74,7 @@ are zeroed out and converted to written extents before being returned to avoid
> exposure of uninitialized data through mmap.
>
> These filesystems may be used for inspiration:
> -- ext2: see Documentation/filesystems/ext2.txt
> +- ext2: see Documentation/filesystems/ext2.rst
> - ext4: see Documentation/filesystems/ext4/
> - xfs: see Documentation/admin-guide/xfs.rst
>
> diff --git a/Documentation/filesystems/dnotify.txt b/Documentation/filesystems/dnotify.txt
> index 15156883d321..08d575ece45d 100644
> --- a/Documentation/filesystems/dnotify.txt
> +++ b/Documentation/filesystems/dnotify.txt
> @@ -67,4 +67,4 @@ See tools/testing/selftests/filesystems/dnotify_test.c for an example.
> NOTE
> ----
> Beginning with Linux 2.6.13, dnotify has been replaced by inotify.
> -See Documentation/filesystems/inotify.txt for more information on it.
> +See Documentation/filesystems/inotify.rst for more information on it.
> diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.rst b/Documentation/filesystems/ramfs-rootfs-initramfs.rst
> index 6c576e241d86..3fddacc6bf14 100644
> --- a/Documentation/filesystems/ramfs-rootfs-initramfs.rst
> +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.rst
> @@ -71,7 +71,7 @@ be allowed write access to a ramfs mount.
>
> A ramfs derivative called tmpfs was created to add size limits, and the ability
> to write the data to swap space. Normal users can be allowed write access to
> -tmpfs mounts. See Documentation/filesystems/tmpfs.txt for more information.
> +tmpfs mounts. See Documentation/filesystems/tmpfs.rst for more information.
>
> What is rootfs?
> ---------------
> diff --git a/Documentation/powerpc/firmware-assisted-dump.rst b/Documentation/powerpc/firmware-assisted-dump.rst
> index b3f3ee135dbe..20ea8cdee0aa 100644
> --- a/Documentation/powerpc/firmware-assisted-dump.rst
> +++ b/Documentation/powerpc/firmware-assisted-dump.rst
> @@ -344,7 +344,7 @@ Here is the list of files under powerpc debugfs:
>
>
> NOTE:
> - Please refer to Documentation/filesystems/debugfs.txt on
> + Please refer to Documentation/filesystems/debugfs.rst on
> how to mount the debugfs filesystem.
>
>
> diff --git a/Documentation/process/adding-syscalls.rst b/Documentation/process/adding-syscalls.rst
> index 1c3a840d06b9..a6b4a3a5bf3f 100644
> --- a/Documentation/process/adding-syscalls.rst
> +++ b/Documentation/process/adding-syscalls.rst
> @@ -33,7 +33,7 @@ interface.
> to a somewhat opaque API.
>
> - If you're just exposing runtime system information, a new node in sysfs
> - (see ``Documentation/filesystems/sysfs.txt``) or the ``/proc`` filesystem may
> + (see ``Documentation/filesystems/sysfs.rst``) or the ``/proc`` filesystem may
> be more appropriate. However, access to these mechanisms requires that the
> relevant filesystem is mounted, which might not always be the case (e.g.
> in a namespaced/sandboxed/chrooted environment). Avoid adding any API to
> diff --git a/Documentation/translations/it_IT/process/adding-syscalls.rst b/Documentation/translations/it_IT/process/adding-syscalls.rst
> index c3a3439595a6..bff0a82bf127 100644
> --- a/Documentation/translations/it_IT/process/adding-syscalls.rst
> +++ b/Documentation/translations/it_IT/process/adding-syscalls.rst
> @@ -39,7 +39,7 @@ vostra interfaccia.
> un qualche modo opaca.
>
> - Se dovete esporre solo delle informazioni sul sistema, un nuovo nodo in
> - sysfs (vedere ``Documentation/filesystems/sysfs.txt``) o
> + sysfs (vedere ``Documentation/filesystems/sysfs.rst``) o
> in procfs potrebbe essere sufficiente. Tuttavia, l'accesso a questi
> meccanismi richiede che il filesystem sia montato, il che potrebbe non
> essere sempre vero (per esempio, in ambienti come namespace/sandbox/chroot).
> diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt
> index ee1f37da5b23..782500d85936 100644
> --- a/Documentation/translations/zh_CN/filesystems/sysfs.txt
> +++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt
> @@ -1,4 +1,4 @@
> -Chinese translated version of Documentation/filesystems/sysfs.txt
> +Chinese translated version of Documentation/filesystems/sysfs.rst
>
> If you have any comment or update to the content, please contact the
> original document maintainer directly. However, if you have a problem
> @@ -10,7 +10,7 @@ Maintainer: Patrick Mochel <mochel@osdl.org>
> Mike Murphy <mamurph@cs.clemson.edu>
> Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
> ---------------------------------------------------------------------
> -Documentation/filesystems/sysfs.txt 的中文翻译
> +Documentation/filesystems/sysfs.rst 的中文翻译
>
> 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
> 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
> @@ -281,7 +281,7 @@ drivers/ 包含了每个已为特定总线上的设备而挂载的驱动程序
> 假定驱动没有跨越多个总线类型)。
>
> fs/ 包含了一个为文件系统设立的目录。现在每个想要导出属性的文件系统必须
> -在 fs/ 下创建自己的层次结构(参见Documentation/filesystems/fuse.txt)。
> +在 fs/ 下创建自己的层次结构(参见Documentation/filesystems/fuse.rst)。
>
> dev/ 包含两个子目录： char/ 和 block/。在这两个子目录中，有以
> <major>:<minor> 格式命名的符号链接。这些符号链接指向 sysfs 目录
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> index 211f5de99a44..9aba2910d83a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> @@ -170,7 +170,7 @@ struct dpu_global_state
> *
> * Main debugfs documentation is located at,
> *
> - * Documentation/filesystems/debugfs.txt
> + * Documentation/filesystems/debugfs.rst
> *
> * @dpu_debugfs_setup_regset32: Initialize data for dpu_debugfs_create_regset32
> * @dpu_debugfs_create_regset32: Create 32-bit register dump file
> diff --git a/fs/Kconfig b/fs/Kconfig
> index f08fbbfafd9a..d1ad3935fb85 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -166,7 +166,7 @@ config TMPFS
> space. If you unmount a tmpfs instance, everything stored therein is
> lost.
>
> - See <file:Documentation/filesystems/tmpfs.txt> for details.
> + See <file:Documentation/filesystems/tmpfs.rst> for details.
>
> config TMPFS_POSIX_ACL
> bool "Tmpfs POSIX Access Control Lists"
> diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
> index 62dc4f577ba1..3fbbd54f50fd 100644
> --- a/fs/Kconfig.binfmt
> +++ b/fs/Kconfig.binfmt
> @@ -72,7 +72,7 @@ config CORE_DUMP_DEFAULT_ELF_HEADERS
>
> The core dump behavior can be controlled per process using
> the /proc/PID/coredump_filter pseudo-file; this setting is
> - inherited. See Documentation/filesystems/proc.txt for details.
> + inherited. See Documentation/filesystems/proc.rst for details.
>
> This config option changes the default setting of coredump_filter
> seen at boot time. If unsure, say Y.
> diff --git a/fs/adfs/Kconfig b/fs/adfs/Kconfig
> index df4650dccf68..44738fed6625 100644
> --- a/fs/adfs/Kconfig
> +++ b/fs/adfs/Kconfig
> @@ -12,7 +12,7 @@ config ADFS_FS
>
> The ADFS partition should be the first partition (i.e.,
> /dev/[hs]d?1) on each of your drives. Please read the file
> - <file:Documentation/filesystems/adfs.txt> for further details.
> + <file:Documentation/filesystems/adfs.rst> for further details.
>
> To compile this code as a module, choose M here: the module will be
> called adfs.
> diff --git a/fs/affs/Kconfig b/fs/affs/Kconfig
> index 84c46b9025c5..eb9d0ab850cb 100644
> --- a/fs/affs/Kconfig
> +++ b/fs/affs/Kconfig
> @@ -9,7 +9,7 @@ config AFFS_FS
> FFS partition on your hard drive. Amiga floppies however cannot be
> read with this driver due to an incompatibility of the floppy
> controller used in an Amiga and the standard floppy controller in
> - PCs and workstations. Read <file:Documentation/filesystems/affs.txt>
> + PCs and workstations. Read <file:Documentation/filesystems/affs.rst>
> and <file:fs/affs/Changes>.
>
> With this driver you can also mount disk files used by Bernd
> diff --git a/fs/afs/Kconfig b/fs/afs/Kconfig
> index 3fb1f559e317..1ad211d72b3b 100644
> --- a/fs/afs/Kconfig
> +++ b/fs/afs/Kconfig
> @@ -8,7 +8,7 @@ config AFS_FS
> If you say Y here, you will get an experimental Andrew File System
> driver. It currently only supports unsecured read-only AFS access.
>
> - See <file:Documentation/filesystems/afs.txt> for more information.
> + See <file:Documentation/filesystems/afs.rst> for more information.
>
> If unsure, say N.
>
> @@ -18,7 +18,7 @@ config AFS_DEBUG
> help
> Say Y here to make runtime controllable debugging messages appear.
>
> - See <file:Documentation/filesystems/afs.txt> for more information.
> + See <file:Documentation/filesystems/afs.rst> for more information.
>
> If unsure, say N.
>
> @@ -37,6 +37,6 @@ config AFS_DEBUG_CURSOR
> the dmesg log if the server rotation algorithm fails to successfully
> contact a server.
>
> - See <file:Documentation/filesystems/afs.txt> for more information.
> + See <file:Documentation/filesystems/afs.rst> for more information.
>
> If unsure, say N.
> diff --git a/fs/bfs/Kconfig b/fs/bfs/Kconfig
> index 3e1247f07913..3a757805b585 100644
> --- a/fs/bfs/Kconfig
> +++ b/fs/bfs/Kconfig
> @@ -11,7 +11,7 @@ config BFS_FS
> on your /stand slice from within Linux. You then also need to say Y
> to "UnixWare slices support", below. More information about the BFS
> file system is contained in the file
> - <file:Documentation/filesystems/bfs.txt>.
> + <file:Documentation/filesystems/bfs.rst>.
>
> If you don't know what this is about, say N.
>
> diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig
> index c8bebb70a971..d98cef0dbb6b 100644
> --- a/fs/cramfs/Kconfig
> +++ b/fs/cramfs/Kconfig
> @@ -9,7 +9,7 @@ config CRAMFS
> limited to 256MB file systems (with 16MB files), and doesn't support
> 16/32 bits uid/gid, hard links and timestamps.
>
> - See <file:Documentation/filesystems/cramfs.txt> and
> + See <file:Documentation/filesystems/cramfs.rst> and
> <file:fs/cramfs/README> for further information.
>
> To compile this as a module, choose M here: the module will be called
> diff --git a/fs/ecryptfs/Kconfig b/fs/ecryptfs/Kconfig
> index 522c35d5292b..1bdeaa6d5790 100644
> --- a/fs/ecryptfs/Kconfig
> +++ b/fs/ecryptfs/Kconfig
> @@ -7,7 +7,7 @@ config ECRYPT_FS
> select CRYPTO_MD5
> help
> Encrypted filesystem that operates on the VFS layer. See
> - <file:Documentation/filesystems/ecryptfs.txt> to learn more about
> + <file:Documentation/filesystems/ecryptfs.rst> to learn more about
> eCryptfs. Userspace components are required and can be
> obtained from <http://ecryptfs.sf.net>.
>
> diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
> index 718163d0c621..ca31993dcb47 100644
> --- a/fs/fat/Kconfig
> +++ b/fs/fat/Kconfig
> @@ -69,7 +69,7 @@ config VFAT_FS
>
> The VFAT support enlarges your kernel by about 10 KB and it only
> works if you said Y to the "DOS FAT fs support" above. Please read
> - the file <file:Documentation/filesystems/vfat.txt> for details. If
> + the file <file:Documentation/filesystems/vfat.rst> for details. If
> unsure, say Y.
>
> To compile this as a module, choose M here: the module will be called
> @@ -82,7 +82,7 @@ config FAT_DEFAULT_CODEPAGE
> help
> This option should be set to the codepage of your FAT filesystems.
> It can be overridden with the "codepage" mount option.
> - See <file:Documentation/filesystems/vfat.txt> for more information.
> + See <file:Documentation/filesystems/vfat.rst> for more information.
>
> config FAT_DEFAULT_IOCHARSET
> string "Default iocharset for FAT"
> @@ -96,7 +96,7 @@ config FAT_DEFAULT_IOCHARSET
> Note that "utf8" is not recommended for FAT filesystems.
> If unsure, you shouldn't set "utf8" here - select the next option
> instead if you would like to use UTF-8 encoded file names by default.
> - See <file:Documentation/filesystems/vfat.txt> for more information.
> + See <file:Documentation/filesystems/vfat.rst> for more information.
>
> Enable any character sets you need in File Systems/Native Language
> Support.
> @@ -114,4 +114,4 @@ config FAT_DEFAULT_UTF8
>
> Say Y if you use UTF-8 encoding for file names, N otherwise.
>
> - See <file:Documentation/filesystems/vfat.txt> for more information.
> + See <file:Documentation/filesystems/vfat.rst> for more information.
> diff --git a/fs/fuse/Kconfig b/fs/fuse/Kconfig
> index eb2a585572dc..774b2618018a 100644
> --- a/fs/fuse/Kconfig
> +++ b/fs/fuse/Kconfig
> @@ -12,7 +12,7 @@ config FUSE_FS
> although chances are your distribution already has that library
> installed if you've installed the "fuse" package itself.
>
> - See <file:Documentation/filesystems/fuse.txt> for more information.
> + See <file:Documentation/filesystems/fuse.rst> for more information.
> See <file:Documentation/Changes> for needed library/utility version.
>
> If you want to develop a userspace FS, or if you want to use
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index 97eec7522bf2..c7a65cf2bcca 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -2081,7 +2081,7 @@ static void end_polls(struct fuse_conn *fc)
> * The same effect is usually achievable through killing the filesystem daemon
> * and all users of the filesystem. The exception is the combination of an
> * asynchronous request and the tricky deadlock (see
> - * Documentation/filesystems/fuse.txt).
> + * Documentation/filesystems/fuse.rst).
> *
> * Aborting requests under I/O goes as follows: 1: Separate out unlocked
> * requests, they should be finished off immediately. Locked requests will be
> diff --git a/fs/hfs/Kconfig b/fs/hfs/Kconfig
> index 44f6e89bcb75..129926b5142d 100644
> --- a/fs/hfs/Kconfig
> +++ b/fs/hfs/Kconfig
> @@ -6,7 +6,7 @@ config HFS_FS
> help
> If you say Y here, you will be able to mount Macintosh-formatted
> floppy disks and hard drive partitions with full read-write access.
> - Please read <file:Documentation/filesystems/hfs.txt> to learn about
> + Please read <file:Documentation/filesystems/hfs.rst> to learn about
> the available mount options.
>
> To compile this file system support as a module, choose M here: the
> diff --git a/fs/hpfs/Kconfig b/fs/hpfs/Kconfig
> index 56aa0336254a..2b36dc6f0a10 100644
> --- a/fs/hpfs/Kconfig
> +++ b/fs/hpfs/Kconfig
> @@ -9,7 +9,7 @@ config HPFS_FS
> write files to an OS/2 HPFS partition on your hard drive. OS/2
> floppies however are in regular MSDOS format, so you don't need this
> option in order to be able to read them. Read
> - <file:Documentation/filesystems/hpfs.txt>.
> + <file:Documentation/filesystems/hpfs.rst>.
>
> To compile this file system support as a module, choose M here: the
> module will be called hpfs. If unsure, say N.
> diff --git a/fs/isofs/Kconfig b/fs/isofs/Kconfig
> index 5e7419599f50..08ffd37b9bb8 100644
> --- a/fs/isofs/Kconfig
> +++ b/fs/isofs/Kconfig
> @@ -8,7 +8,7 @@ config ISO9660_FS
> long Unix filenames and symbolic links are also supported by this
> driver. If you have a CD-ROM drive and want to do more with it than
> just listen to audio CDs and watch its LEDs, say Y (and read
> - <file:Documentation/filesystems/isofs.txt> and the CD-ROM-HOWTO,
> + <file:Documentation/filesystems/isofs.rst> and the CD-ROM-HOWTO,
> available from <http://www.tldp.org/docs.html#howto>), thereby
> enlarging your kernel by about 27 KB; otherwise say N.
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index e6aed405611d..894a1d12fe5f 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -3592,7 +3592,7 @@ EXPORT_SYMBOL(path_is_under);
> * file system may be mounted on put_old. After all, new_root is a mountpoint.
> *
> * Also, the current root cannot be on the 'rootfs' (initial ramfs) filesystem.
> - * See Documentation/filesystems/ramfs-rootfs-initramfs.txt for alternatives
> + * See Documentation/filesystems/ramfs-rootfs-initramfs.rst for alternatives
> * in this situation.
> *
> * Notes:
> diff --git a/fs/notify/inotify/Kconfig b/fs/notify/inotify/Kconfig
> index 6736e47d94d8..7715fadd5fff 100644
> --- a/fs/notify/inotify/Kconfig
> +++ b/fs/notify/inotify/Kconfig
> @@ -12,6 +12,6 @@ config INOTIFY_USER
> new features including multiple file events, one-shot support, and
> unmount notification.
>
> - For more information, see <file:Documentation/filesystems/inotify.txt>
> + For more information, see <file:Documentation/filesystems/inotify.rst>
>
> If unsure, say Y.
> diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig
> index de9fb5cff226..1667a7e590d8 100644
> --- a/fs/ntfs/Kconfig
> +++ b/fs/ntfs/Kconfig
> @@ -18,7 +18,7 @@ config NTFS_FS
> the Linux 2.4 kernel series is separately available as a patch
> from the project web site.
>
> - For more information see <file:Documentation/filesystems/ntfs.txt>
> + For more information see <file:Documentation/filesystems/ntfs.rst>
> and <http://www.linux-ntfs.org/>.
>
> To compile this file system support as a module, choose M here: the
> diff --git a/fs/ocfs2/Kconfig b/fs/ocfs2/Kconfig
> index 46bba20da6b5..1177c33df895 100644
> --- a/fs/ocfs2/Kconfig
> +++ b/fs/ocfs2/Kconfig
> @@ -21,7 +21,7 @@ config OCFS2_FS
> OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/
>
> For more information on OCFS2, see the file
> - <file:Documentation/filesystems/ocfs2.txt>.
> + <file:Documentation/filesystems/ocfs2.rst>.
>
> config OCFS2_FS_O2CB
> tristate "O2CB Kernelspace Clustering"
> diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig
> index 714c14c47ca5..dd188c7996b3 100644
> --- a/fs/overlayfs/Kconfig
> +++ b/fs/overlayfs/Kconfig
> @@ -9,7 +9,7 @@ config OVERLAY_FS
> 'lower' filesystem is either hidden or, in the case of directories,
> merged with the 'upper' object.
>
> - For more information see Documentation/filesystems/overlayfs.txt
> + For more information see Documentation/filesystems/overlayfs.rst
>
> config OVERLAY_FS_REDIRECT_DIR
> bool "Overlayfs: turn on redirect directory feature by default"
> @@ -38,7 +38,7 @@ config OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW
> If backward compatibility is not an issue, then it is safe and
> recommended to say N here.
>
> - For more information, see Documentation/filesystems/overlayfs.txt
> + For more information, see Documentation/filesystems/overlayfs.rst
>
> If unsure, say Y.
>
> @@ -103,7 +103,7 @@ config OVERLAY_FS_XINO_AUTO
> If compatibility with applications that expect 32bit inodes is not an
> issue, then it is safe and recommended to say Y here.
>
> - For more information, see Documentation/filesystems/overlayfs.txt
> + For more information, see Documentation/filesystems/overlayfs.rst
>
> If unsure, say N.
>
> diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
> index 27ef84d99f59..971a42f6357d 100644
> --- a/fs/proc/Kconfig
> +++ b/fs/proc/Kconfig
> @@ -23,7 +23,7 @@ config PROC_FS
> /proc" or the equivalent line in /etc/fstab does the job.
>
> The /proc file system is explained in the file
> - <file:Documentation/filesystems/proc.txt> and on the proc(5) manpage
> + <file:Documentation/filesystems/proc.rst> and on the proc(5) manpage
> ("man 5 proc").
>
> This option will enlarge your kernel by about 67 KB. Several
> @@ -95,7 +95,7 @@ config PROC_CHILDREN
> default n
> help
> Provides a fast way to retrieve first level children pids of a task. See
> - <file:Documentation/filesystems/proc.txt> for more information.
> + <file:Documentation/filesystems/proc.rst> for more information.
>
> Say Y if you are running any user-space software which takes benefit from
> this interface. For example, rkt is such a piece of software.
> diff --git a/fs/romfs/Kconfig b/fs/romfs/Kconfig
> index ad4c45788896..9737b8e68878 100644
> --- a/fs/romfs/Kconfig
> +++ b/fs/romfs/Kconfig
> @@ -6,7 +6,7 @@ config ROMFS_FS
> This is a very small read-only file system mainly intended for
> initial ram disks of installation disks, but it could be used for
> other read-only media as well. Read
> - <file:Documentation/filesystems/romfs.txt> for details.
> + <file:Documentation/filesystems/romfs.rst> for details.
>
> To compile this file system support as a module, choose M here: the
> module will be called romfs. Note that the file system of your
> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> index aa85f2874a9f..59dffd5ca517 100644
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -6,7 +6,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #define pr_fmt(fmt) "sysfs: " fmt
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 26bbf960e2a2..f275fcda62fb 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -6,7 +6,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #include <linux/module.h>
> diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
> index db81cfbab9d6..e747c135c1d1 100644
> --- a/fs/sysfs/mount.c
> +++ b/fs/sysfs/mount.c
> @@ -6,7 +6,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #include <linux/fs.h>
> diff --git a/fs/sysfs/symlink.c b/fs/sysfs/symlink.c
> index c4deecc80f67..5603530a1a52 100644
> --- a/fs/sysfs/symlink.c
> +++ b/fs/sysfs/symlink.c
> @@ -6,7 +6,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #include <linux/fs.h>
> diff --git a/fs/sysv/Kconfig b/fs/sysv/Kconfig
> index d4edf7d9ae10..b4e23e03fbeb 100644
> --- a/fs/sysv/Kconfig
> +++ b/fs/sysv/Kconfig
> @@ -28,7 +28,7 @@ config SYSV_FS
> tar" or preferably "info tar"). Note also that this option has
> nothing whatsoever to do with the option "System V IPC". Read about
> the System V file system in
> - <file:Documentation/filesystems/sysv-fs.txt>.
> + <file:Documentation/filesystems/sysv-fs.rst>.
> Saying Y here will enlarge your kernel by about 27 KB.
>
> To compile this as a module, choose M here: the module will be called
> diff --git a/fs/udf/Kconfig b/fs/udf/Kconfig
> index 6848de581ce1..26e1a49f3ba7 100644
> --- a/fs/udf/Kconfig
> +++ b/fs/udf/Kconfig
> @@ -9,7 +9,7 @@ config UDF_FS
> compatible with standard unix file systems, it is also suitable for
> removable USB disks. Say Y if you intend to mount DVD discs or CDRW's
> written in packet mode, or if you want to use UDF for removable USB
> - disks. Please read <file:Documentation/filesystems/udf.txt>.
> + disks. Please read <file:Documentation/filesystems/udf.rst>.
>
> To compile this file system support as a module, choose M here: the
> module will be called udf.
> diff --git a/include/linux/relay.h b/include/linux/relay.h
> index c759f96e39c1..e13a333e7c37 100644
> --- a/include/linux/relay.h
> +++ b/include/linux/relay.h
> @@ -141,7 +141,7 @@ struct rchan_callbacks
> * cause relay_open() to create a single global buffer rather
> * than the default set of per-cpu buffers.
> *
> - * See Documentation/filesystems/relay.txt for more info.
> + * See Documentation/filesystems/relay.rst for more info.
> */
> struct dentry *(*create_buf_file)(const char *filename,
> struct dentry *parent,
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index 80bb865b3a33..86067dbe7745 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -7,7 +7,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #ifndef _SYSFS_H_
> diff --git a/kernel/relay.c b/kernel/relay.c
> index 07ee1a791d85..628f570ca678 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -1,7 +1,7 @@
> /*
> * Public API and common code for kernel->userspace relay file support.
> *
> - * See Documentation/filesystems/relay.txt for an overview.
> + * See Documentation/filesystems/relay.rst for an overview.
> *
> * Copyright (C) 2002-2005 - Tom Zanussi (zanussi@us.ibm.com), IBM Corp
> * Copyright (C) 1999-2005 - Karim Yaghmour (karim@opersys.com)
>
^ permalink raw reply
* Re: [PATCH kernel v2 0/7] powerpc/powenv/ioda: Allow huge DMA window at 4GB
From: Alexey Kardashevskiy @ 2020-04-16 1:27 UTC (permalink / raw)
To: linuxppc-dev
Cc: kvm, Fabiano Rosas, Alistair Popple, kvm-ppc, Oliver,
David Gibson
In-Reply-To: <b512ac5e-dca5-4c08-8ea1-a636b887c0d0@ozlabs.ru>
Anyone? Is it totally useless or wrong approach? Thanks,
On 08/04/2020 19:43, Alexey Kardashevskiy wrote:
>
>
> On 23/03/2020 18:53, Alexey Kardashevskiy wrote:
>> Here is an attempt to support bigger DMA space for devices
>> supporting DMA masks less than 59 bits (GPUs come into mind
>> first). POWER9 PHBs have an option to map 2 windows at 0
>> and select a windows based on DMA address being below or above
>> 4GB.
>>
>> This adds the "iommu=iommu_bypass" kernel parameter and
>> supports VFIO+pseries machine - current this requires telling
>> upstream+unmodified QEMU about this via
>> -global spapr-pci-host-bridge.dma64_win_addr=0x100000000
>> or per-phb property. 4/4 advertises the new option but
>> there is no automation around it in QEMU (should it be?).
>>
>> For now it is either 1<<59 or 4GB mode; dynamic switching is
>> not supported (could be via sysfs).
>>
>> This is a rebased version of
>> https://lore.kernel.org/kvm/20191202015953.127902-1-aik@ozlabs.ru/
>>
>> The main change since v1 is that now it is 7 patches with
>> clearer separation of steps.
>>
>>
>> This is based on 6c90b86a745a "Merge tag 'mmc-v5.6-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc"
>>
>> Please comment. Thanks.
>
> Ping?
>
>
>>
>>
>>
>> Alexey Kardashevskiy (7):
>> powerpc/powernv/ioda: Move TCE bypass base to PE
>> powerpc/powernv/ioda: Rework for huge DMA window at 4GB
>> powerpc/powernv/ioda: Allow smaller TCE table levels
>> powerpc/powernv/phb4: Use IOMMU instead of bypassing
>> powerpc/iommu: Add a window number to
>> iommu_table_group_ops::get_table_size
>> powerpc/powernv/phb4: Add 4GB IOMMU bypass mode
>> vfio/spapr_tce: Advertise and allow a huge DMA windows at 4GB
>>
>> arch/powerpc/include/asm/iommu.h | 3 +
>> arch/powerpc/include/asm/opal-api.h | 9 +-
>> arch/powerpc/include/asm/opal.h | 2 +
>> arch/powerpc/platforms/powernv/pci.h | 4 +-
>> include/uapi/linux/vfio.h | 2 +
>> arch/powerpc/platforms/powernv/npu-dma.c | 1 +
>> arch/powerpc/platforms/powernv/opal-call.c | 2 +
>> arch/powerpc/platforms/powernv/pci-ioda-tce.c | 4 +-
>> arch/powerpc/platforms/powernv/pci-ioda.c | 234 ++++++++++++++----
>> drivers/vfio/vfio_iommu_spapr_tce.c | 17 +-
>> 10 files changed, 213 insertions(+), 65 deletions(-)
>>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable
From: kbuild test robot @ 2020-04-16 0:58 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, oss, christophe.leroy,
linuxppc-dev
Cc: kernel, Wang Wenhu, kbuild-all
In-Reply-To: <20200415123346.116212-2-wenhu.wang@vivo.com>
[-- Attachment #1: Type: text/plain, Size: 21439 bytes --]
Hi Wang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on char-misc/char-misc-testing staging/staging-testing v5.7-rc1 next-20200415]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Wang-Wenhu/drivers-uio-new-driver-uio_fsl_85xx_cache_sram/20200416-040633
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.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
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
WARNING: unmet direct dependencies detected for ARCH_32BIT_OFF_T
Depends on !64BIT
Selected by
- PPC && PPC32
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:14:3: error: conflicting types for 'atomic64_t'
14 | } atomic64_t;
| ^~~~~~~~~~
In file included from include/linux/page-flags.h:9,
from kernel/bounds.c:10:
include/linux/types.h:178:3: note: previous declaration of 'atomic64_t' was here
178 | } atomic64_t;
| ^~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:18:12: error: conflicting types for 'atomic64_read'
18 | extern s64 atomic64_read(const atomic64_t
| ^~~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:300:23: note: previous definition of 'atomic64_read' was here
300 | static __inline__ s64 atomic64_read(const atomic64_t
| ^~~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:19:13: error: conflicting types for 'atomic64_set'
19 | extern void atomic64_set(atomic64_t s64 i);
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:309:24: note: previous definition of 'atomic64_set' was here
309 | static __inline__ void atomic64_set(atomic64_t s64 i)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:32: warning: "ATOMIC64_OPS" redefined
32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
|
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:380: note: this is the location of the previous definition
380 | #define ATOMIC64_OPS(op, asm_op) |
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_add'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
>> include/asm-generic/atomic64.h:32:26: note: in expansion of macro 'ATOMIC64_OP'
32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
>> include/asm-generic/atomic64.h:34:1: note: in expansion of macro 'ATOMIC64_OPS'
34 | ATOMIC64_OPS(add)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_add' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
>> arch/powerpc/include/asm/atomic.h:366:2: note: in expansion of macro 'ATOMIC64_OP'
366 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
>> arch/powerpc/include/asm/atomic.h:370:1: note: in expansion of macro 'ATOMIC64_OPS'
370 | ATOMIC64_OPS(add, add)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_sub'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
>> include/asm-generic/atomic64.h:32:26: note: in expansion of macro 'ATOMIC64_OP'
32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
include/asm-generic/atomic64.h:35:1: note: in expansion of macro 'ATOMIC64_OPS'
35 | ATOMIC64_OPS(sub)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_sub' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
>> arch/powerpc/include/asm/atomic.h:366:2: note: in expansion of macro 'ATOMIC64_OP'
366 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:371:1: note: in expansion of macro 'ATOMIC64_OPS'
371 | ATOMIC64_OPS(sub, subf)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_and'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
include/asm-generic/atomic64.h:38:26: note: in expansion of macro 'ATOMIC64_OP'
38 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
include/asm-generic/atomic64.h:40:1: note: in expansion of macro 'ATOMIC64_OPS'
40 | ATOMIC64_OPS(and)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_and' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
arch/powerpc/include/asm/atomic.h:381:2: note: in expansion of macro 'ATOMIC64_OP'
381 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:384:1: note: in expansion of macro 'ATOMIC64_OPS'
384 | ATOMIC64_OPS(and, and)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_or'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
include/asm-generic/atomic64.h:38:26: note: in expansion of macro 'ATOMIC64_OP'
38 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
include/asm-generic/atomic64.h:41:1: note: in expansion of macro 'ATOMIC64_OPS'
41 | ATOMIC64_OPS(or)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_or' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
arch/powerpc/include/asm/atomic.h:381:2: note: in expansion of macro 'ATOMIC64_OP'
381 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:385:1: note: in expansion of macro 'ATOMIC64_OPS'
385 | ATOMIC64_OPS(or, or)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_xor'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
include/asm-generic/atomic64.h:38:26: note: in expansion of macro 'ATOMIC64_OP'
38 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
include/asm-generic/atomic64.h:42:1: note: in expansion of macro 'ATOMIC64_OPS'
42 | ATOMIC64_OPS(xor)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_xor' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
arch/powerpc/include/asm/atomic.h:381:2: note: in expansion of macro 'ATOMIC64_OP'
381 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:386:1: note: in expansion of macro 'ATOMIC64_OPS'
386 | ATOMIC64_OPS(xor, xor)
| ^~~~~~~~~~~~
>> arch/powerpc/include/asm/atomic.h:485:34: error: conflicting types for 'atomic64_dec_if_positive'
485 | #define atomic64_dec_if_positive atomic64_dec_if_positive
| ^~~~~~~~~~~~~~~~~~~~~~~~
>> include/asm-generic/atomic64.h:49:12: note: in expansion of macro 'atomic64_dec_if_positive'
49 | extern s64 atomic64_dec_if_positive(atomic64_t
| ^~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:466:23: note: previous definition of 'atomic64_dec_if_positive' was here
466 | static __inline__ s64 atomic64_dec_if_positive(atomic64_t
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from arch/powerpc/include/asm/atomic.h:11,
from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> arch/powerpc/include/asm/cmpxchg.h:482:4: error: expected identifier or '(' before '{' token
482 | ({ | ^
>> arch/powerpc/include/asm/atomic.h:487:36: note: in expansion of macro 'cmpxchg'
487 | #define atomic64_cmpxchg(v, o, n) (cmpxchg(&((v)->counter), (o), (n)))
| ^~~~~~~
>> include/asm-generic/atomic64.h:51:12: note: in expansion of macro 'atomic64_cmpxchg'
51 | extern s64 atomic64_cmpxchg(atomic64_t s64 o, s64 n);
| ^~~~~~~~~~~~~~~~
In file included from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/linux/atomic.h:66:2: error: expected identifier or '(' before '{' token
66 | ({ | ^
include/linux/atomic-fallback.h:27:2: note: in expansion of macro '__atomic_op_fence'
27 | __atomic_op_fence(xchg, __VA_ARGS__)
| ^~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:493:32: note: in expansion of macro 'xchg'
493 | #define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
| ^~~~
include/asm-generic/atomic64.h:52:12: note: in expansion of macro 'atomic64_xchg'
52 | extern s64 atomic64_xchg(atomic64_t s64 new);
| ^~~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:526:35: error: conflicting types for 'atomic64_fetch_add_unless'
526 | #define atomic64_fetch_add_unless atomic64_fetch_add_unless
| ^~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/atomic64.h:53:12: note: in expansion of macro 'atomic64_fetch_add_unless'
53 | extern s64 atomic64_fetch_add_unless(atomic64_t s64 a, s64 u);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:505:23: note: previous definition of 'atomic64_fetch_add_unless' was here
505 | static __inline__ s64 atomic64_fetch_add_unless(atomic64_t s64 a, s64 u)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/linux/atomic-fallback.h: In function 'atomic64_add_return_acquire':
include/linux/atomic-fallback.h:1216:43: error: passing argument 2 of 'atomic64_add_return_relaxed' from incompatible pointer type
1216 | s64 ret = atomic64_add_return_relaxed(i, v);
| ^
| |
| atomic64_t Makefile arch block certs crypto drivers fs include init ipc kernel lib mm net scripts security sound source usr virt {aka struct <anonymous>
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:331:51: note: expected 'atomic64_t {aka 'struct <anonymous> but argument is of type 'atomic64_t {aka 'struct <anonymous>
331 | atomic64_##op##_return_relaxed(s64 a, atomic64_t | ~~~~~~~~~~~~^
arch/powerpc/include/asm/atomic.h:367:2: note: in expansion of macro 'ATOMIC64_OP_RETURN_RELAXED'
367 | ATOMIC64_OP_RETURN_RELAXED(op, asm_op) | ^~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:370:1: note: in expansion of macro 'ATOMIC64_OPS'
370 | ATOMIC64_OPS(add, add)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/linux/atomic-fallback.h: In function 'atomic64_add_return_release':
include/linux/atomic-fallback.h:1228:40: error: passing argument 2 of 'atomic64_add_return_relaxed' from incompatible pointer type
1228 | return atomic64_add_return_relaxed(i, v);
| ^
| |
| atomic64_t Makefile arch block certs crypto drivers fs include init ipc kernel lib mm net scripts security sound source usr virt {aka struct <anonymous>
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:331:51: note: expected 'atomic64_t {aka 'struct <anonymous> but argument is of type 'atomic64_t {aka 'struct <anonymous>
331 | atomic64_##op##_return_relaxed(s64 a, atomic64_t | ~~~~~~~~~~~~^
arch/powerpc/include/asm/atomic.h:367:2: note: in expansion of macro 'ATOMIC64_OP_RETURN_RELAXED'
367 | ATOMIC64_OP_RETURN_RELAXED(op, asm_op) | ^~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:370:1: note: in expansion of macro 'ATOMIC64_OPS'
370 | ATOMIC64_OPS(add, add)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/linux/atomic-fallback.h: At top level:
include/linux/atomic-fallback.h:1235:1: error: static declaration of 'atomic64_add_return' follows non-static declaration
1235 | atomic64_add_return(s64 i, atomic64_t
| ^~~~~~~~~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/asm-generic/atomic64.h:27:12: note: previous declaration of 'atomic64_add_return' was here
27 | extern s64 atomic64_##op##_return(s64 a, atomic64_t
| ^~~~~~~~~
include/asm-generic/atomic64.h:32:42: note: in expansion of macro 'ATOMIC64_OP_RETURN'
32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~~~~~~~~
include/asm-generic/atomic64.h:34:1: note: in expansion of macro 'ATOMIC64_OPS'
34 | ATOMIC64_OPS(add)
vim +/atomic64_t +14 include/asm-generic/atomic64.h
09d4e0edd4614e7 Paul Mackerras 2009-06-12 11
09d4e0edd4614e7 Paul Mackerras 2009-06-12 12 typedef struct {
9255813d5841e15 Mark Rutland 2019-05-22 13 s64 counter;
09d4e0edd4614e7 Paul Mackerras 2009-06-12 @14 } atomic64_t;
09d4e0edd4614e7 Paul Mackerras 2009-06-12 15
09d4e0edd4614e7 Paul Mackerras 2009-06-12 16 #define ATOMIC64_INIT(i) { (i) }
09d4e0edd4614e7 Paul Mackerras 2009-06-12 17
9255813d5841e15 Mark Rutland 2019-05-22 @18 extern s64 atomic64_read(const atomic64_t *v);
9255813d5841e15 Mark Rutland 2019-05-22 @19 extern void atomic64_set(atomic64_t *v, s64 i);
560cb12a4080a48 Peter Zijlstra 2014-04-23 20
9d664c0aec3bfdb Peter Zijlstra 2017-06-09 21 #define atomic64_set_release(v, i) atomic64_set((v), (i))
9d664c0aec3bfdb Peter Zijlstra 2017-06-09 22
560cb12a4080a48 Peter Zijlstra 2014-04-23 23 #define ATOMIC64_OP(op) \
9255813d5841e15 Mark Rutland 2019-05-22 @24 extern void atomic64_##op(s64 a, atomic64_t *v);
560cb12a4080a48 Peter Zijlstra 2014-04-23 25
560cb12a4080a48 Peter Zijlstra 2014-04-23 26 #define ATOMIC64_OP_RETURN(op) \
9255813d5841e15 Mark Rutland 2019-05-22 27 extern s64 atomic64_##op##_return(s64 a, atomic64_t *v);
560cb12a4080a48 Peter Zijlstra 2014-04-23 28
28aa2bda2211f43 Peter Zijlstra 2016-04-18 29 #define ATOMIC64_FETCH_OP(op) \
9255813d5841e15 Mark Rutland 2019-05-22 30 extern s64 atomic64_fetch_##op(s64 a, atomic64_t *v);
28aa2bda2211f43 Peter Zijlstra 2016-04-18 31
28aa2bda2211f43 Peter Zijlstra 2016-04-18 @32 #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
560cb12a4080a48 Peter Zijlstra 2014-04-23 33
560cb12a4080a48 Peter Zijlstra 2014-04-23 @34 ATOMIC64_OPS(add)
560cb12a4080a48 Peter Zijlstra 2014-04-23 35 ATOMIC64_OPS(sub)
560cb12a4080a48 Peter Zijlstra 2014-04-23 36
28aa2bda2211f43 Peter Zijlstra 2016-04-18 37 #undef ATOMIC64_OPS
28aa2bda2211f43 Peter Zijlstra 2016-04-18 38 #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op)
28aa2bda2211f43 Peter Zijlstra 2016-04-18 39
28aa2bda2211f43 Peter Zijlstra 2016-04-18 40 ATOMIC64_OPS(and)
28aa2bda2211f43 Peter Zijlstra 2016-04-18 41 ATOMIC64_OPS(or)
28aa2bda2211f43 Peter Zijlstra 2016-04-18 42 ATOMIC64_OPS(xor)
e6942b7de2dfe44 Peter Zijlstra 2014-04-23 43
560cb12a4080a48 Peter Zijlstra 2014-04-23 44 #undef ATOMIC64_OPS
28aa2bda2211f43 Peter Zijlstra 2016-04-18 45 #undef ATOMIC64_FETCH_OP
560cb12a4080a48 Peter Zijlstra 2014-04-23 46 #undef ATOMIC64_OP_RETURN
560cb12a4080a48 Peter Zijlstra 2014-04-23 47 #undef ATOMIC64_OP
560cb12a4080a48 Peter Zijlstra 2014-04-23 48
9255813d5841e15 Mark Rutland 2019-05-22 @49 extern s64 atomic64_dec_if_positive(atomic64_t *v);
b3a2a05f9111de0 Mark Rutland 2018-06-21 50 #define atomic64_dec_if_positive atomic64_dec_if_positive
9255813d5841e15 Mark Rutland 2019-05-22 @51 extern s64 atomic64_cmpxchg(atomic64_t *v, s64 o, s64 n);
9255813d5841e15 Mark Rutland 2019-05-22 @52 extern s64 atomic64_xchg(atomic64_t *v, s64 new);
9255813d5841e15 Mark Rutland 2019-05-22 @53 extern s64 atomic64_fetch_add_unless(atomic64_t *v, s64 a, s64 u);
00b808ab79ead37 Mark Rutland 2018-06-21 54 #define atomic64_fetch_add_unless atomic64_fetch_add_unless
09d4e0edd4614e7 Paul Mackerras 2009-06-12 55
:::::: The code at line 14 was first introduced by commit
:::::: 09d4e0edd4614e787393acc582ac701c6ec3565b lib: Provide generic atomic64_t implementation
:::::: TO: Paul Mackerras <paulus@samba.org>
:::::: CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 68870 bytes --]
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 0:48 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <1586994952.nnxigedbu2.astroid@bobo.none>
On Thu, Apr 16, 2020 at 10:16:54AM +1000, Nicholas Piggin wrote:
> Excerpts from Rich Felker's message of April 16, 2020 8:55 am:
> > On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote:
> >> I would like to enable Linux support for the powerpc 'scv' instruction,
> >> as a faster system call instruction.
> >>
> >> This requires two things to be defined: Firstly a way to advertise to
> >> userspace that kernel supports scv, and a way to allocate and advertise
> >> support for individual scv vectors. Secondly, a calling convention ABI
> >> for this new instruction.
> >>
> >> Thanks to those who commented last time, since then I have removed my
> >> answered questions and unpopular alternatives but you can find them
> >> here
> >>
> >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
> >>
> >> Let me try one more with a wider cc list, and then we'll get something
> >> merged. Any questions or counter-opinions are welcome.
> >>
> >> System Call Vectored (scv) ABI
> >> ==============================
> >>
> >> The scv instruction is introduced with POWER9 / ISA3, it comes with an
> >> rfscv counter-part. The benefit of these instructions is performance
> >> (trading slower SRR0/1 with faster LR/CTR registers, and entering the
> >> kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
> >> updates. The scv instruction has 128 interrupt entry points (not enough
> >> to cover the Linux system call space).
> >>
> >> The proposal is to assign scv numbers very conservatively and allocate
> >> them as individual HWCAP features as we add support for more. The zero
> >> vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
> >>
> >> Advertisement
> >>
> >> Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
> >> SIGILL in current environments. Linux has defined a HWCAP2 bit
> >> PPC_FEATURE2_SCV for SCV support, but does not set it.
> >>
> >> When scv instruction support and the scv 0 vector for system calls are
> >> added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
> >> should not be used without future HWCAP bits indicating support, which is
> >> how we will allocate them. (Should unallocated ones generate SIGILL, or
> >> return -ENOSYS in r3?)
> >>
> >> Calling convention
> >>
> >> The proposal is for scv 0 to provide the standard Linux system call ABI
> >> with the following differences from sc convention[1]:
> >>
> >> - LR is to be volatile across scv calls. This is necessary because the
> >> scv instruction clobbers LR. From previous discussion, this should be
> >> possible to deal with in GCC clobbers and CFI.
> >>
> >> - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
> >> kernel system call exit to avoid restoring the CR register (although
> >> we probably still would anyway to avoid information leak).
> >>
> >> - Error handling: I think the consensus has been to move to using negative
> >> return value in r3 rather than CR0[SO]=1 to indicate error, which matches
> >> most other architectures and is closer to a function call.
> >>
> >> The number of scratch registers (r9-r12) at kernel entry seems
> >> sufficient that we don't have any costly spilling, patch is here[2].
> >>
> >> [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
> >> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840..html
> >
> > My preference would be that it work just like the i386 AT_SYSINFO
> > where you just replace "int $128" with "call *%%gs:16" and the kernel
> > provides a stub in the vdso that performs either scv or the old
> > mechanism with the same calling convention. Then if the kernel doesn't
> > provide it (because the kernel is too old) libc would have to provide
> > its own stub that uses the legacy method and matches the calling
> > convention of the one the kernel is expected to provide.
>
> I'm not sure if that's necessary. That's done on x86-32 because they
> select different sequences to use based on the CPU running and if the host
> kernel is 32 or 64 bit. Sure they could in theory have a bunch of HWCAP
> bits and select the right sequence in libc as well I suppose.
It's not just a HWCAP. It's a contract between the kernel and
userspace to support a particular calling convention that's not
exposed except as the public entry point the kernel exports via
AT_SYSINFO.
> > Note that any libc that actually makes use of the new functionality is
> > not going to be able to make clobbers conditional on support for it;
> > branching around different clobbers is going to defeat any gains vs
> > always just treating anything clobbered by either method as clobbered.
>
> Well it would have to test HWCAP and patch in or branch to two
> completely different sequences including register save/restores yes.
> You could have the same asm and matching clobbers to put the sequence
> inline and then you could patch the one sc/scv instruction I suppose.
>
> A bit of logic to select between them doesn't defeat gains though,
> it's about 90 cycle improvement which is a handful of branch mispredicts
> so it really is an improvement. Eventually userspace will stop
> supporting the old variant too.
Oh, I didn't mean it would neutralize the benefit of svc. Rather, I
meant it would be worse to do:
if (hwcap & X) {
__asm__(... with some clobbers);
} else {
__asm__(... with different clobbers);
}
instead of just
__asm__("indirect call" ... with common clobbers);
where the indirect call is to an address ideally provided like on
i386, or otherwise initialized to one of two or more code addresses in
libc based on hwcap bits.
> > Likewise, it's not useful to have different error return mechanisms
> > because the caller just has to branch to support both (or the
> > kernel-provided stub just has to emulate one for it; that could work
> > if you really want to change the bad existing convention).
> >
> > Thoughts?
>
> The existing convention has to change somewhat because of the clobbers,
> so I thought we could change the error return at the same time. I'm
> open to not changing it and using CR0[SO], but others liked the idea.
> Pro: it matches sc and vsyscall. Con: it's different from other common
> archs. Performnce-wise it would really be a wash -- cost of conditional
> branch is not the cmp but the mispredict.
If you do the branch on hwcap at each syscall, then you significantly
increase code size of every syscall point, likely turning a bunch of
trivial functions that didn't need stack frames into ones that do. You
also potentially make them need a TOC pointer. Making them all just do
an indirect call unconditionally (with pointer in TLS like i386?) is a
lot more efficient in code size and at least as good for performance.
Rich
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Nicholas Piggin @ 2020-04-16 0:16 UTC (permalink / raw)
To: Rich Felker; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <20200415225539.GL11469@brightrain.aerifal.cx>
Excerpts from Rich Felker's message of April 16, 2020 8:55 am:
> On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote:
>> I would like to enable Linux support for the powerpc 'scv' instruction,
>> as a faster system call instruction.
>>
>> This requires two things to be defined: Firstly a way to advertise to
>> userspace that kernel supports scv, and a way to allocate and advertise
>> support for individual scv vectors. Secondly, a calling convention ABI
>> for this new instruction.
>>
>> Thanks to those who commented last time, since then I have removed my
>> answered questions and unpopular alternatives but you can find them
>> here
>>
>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
>>
>> Let me try one more with a wider cc list, and then we'll get something
>> merged. Any questions or counter-opinions are welcome.
>>
>> System Call Vectored (scv) ABI
>> ==============================
>>
>> The scv instruction is introduced with POWER9 / ISA3, it comes with an
>> rfscv counter-part. The benefit of these instructions is performance
>> (trading slower SRR0/1 with faster LR/CTR registers, and entering the
>> kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
>> updates. The scv instruction has 128 interrupt entry points (not enough
>> to cover the Linux system call space).
>>
>> The proposal is to assign scv numbers very conservatively and allocate
>> them as individual HWCAP features as we add support for more. The zero
>> vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
>>
>> Advertisement
>>
>> Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
>> SIGILL in current environments. Linux has defined a HWCAP2 bit
>> PPC_FEATURE2_SCV for SCV support, but does not set it.
>>
>> When scv instruction support and the scv 0 vector for system calls are
>> added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
>> should not be used without future HWCAP bits indicating support, which is
>> how we will allocate them. (Should unallocated ones generate SIGILL, or
>> return -ENOSYS in r3?)
>>
>> Calling convention
>>
>> The proposal is for scv 0 to provide the standard Linux system call ABI
>> with the following differences from sc convention[1]:
>>
>> - LR is to be volatile across scv calls. This is necessary because the
>> scv instruction clobbers LR. From previous discussion, this should be
>> possible to deal with in GCC clobbers and CFI.
>>
>> - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
>> kernel system call exit to avoid restoring the CR register (although
>> we probably still would anyway to avoid information leak).
>>
>> - Error handling: I think the consensus has been to move to using negative
>> return value in r3 rather than CR0[SO]=1 to indicate error, which matches
>> most other architectures and is closer to a function call.
>>
>> The number of scratch registers (r9-r12) at kernel entry seems
>> sufficient that we don't have any costly spilling, patch is here[2].
>>
>> [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
>> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840.html
>
> My preference would be that it work just like the i386 AT_SYSINFO
> where you just replace "int $128" with "call *%%gs:16" and the kernel
> provides a stub in the vdso that performs either scv or the old
> mechanism with the same calling convention. Then if the kernel doesn't
> provide it (because the kernel is too old) libc would have to provide
> its own stub that uses the legacy method and matches the calling
> convention of the one the kernel is expected to provide.
I'm not sure if that's necessary. That's done on x86-32 because they
select different sequences to use based on the CPU running and if the host
kernel is 32 or 64 bit. Sure they could in theory have a bunch of HWCAP
bits and select the right sequence in libc as well I suppose.
> Note that any libc that actually makes use of the new functionality is
> not going to be able to make clobbers conditional on support for it;
> branching around different clobbers is going to defeat any gains vs
> always just treating anything clobbered by either method as clobbered.
Well it would have to test HWCAP and patch in or branch to two
completely different sequences including register save/restores yes.
You could have the same asm and matching clobbers to put the sequence
inline and then you could patch the one sc/scv instruction I suppose.
A bit of logic to select between them doesn't defeat gains though,
it's about 90 cycle improvement which is a handful of branch mispredicts
so it really is an improvement. Eventually userspace will stop
supporting the old variant too.
> Likewise, it's not useful to have different error return mechanisms
> because the caller just has to branch to support both (or the
> kernel-provided stub just has to emulate one for it; that could work
> if you really want to change the bad existing convention).
>
> Thoughts?
The existing convention has to change somewhat because of the clobbers,
so I thought we could change the error return at the same time. I'm
open to not changing it and using CR0[SO], but others liked the idea.
Pro: it matches sc and vsyscall. Con: it's different from other common
archs. Performnce-wise it would really be a wash -- cost of conditional
branch is not the cmp but the mispredict.
Thanks,
Nick
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-15 22:55 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: libc-alpha, musl, linuxppc-dev, libc-dev
In-Reply-To: <1586931450.ub4c8cq8dj.astroid@bobo.none>
On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote:
> I would like to enable Linux support for the powerpc 'scv' instruction,
> as a faster system call instruction.
>
> This requires two things to be defined: Firstly a way to advertise to
> userspace that kernel supports scv, and a way to allocate and advertise
> support for individual scv vectors. Secondly, a calling convention ABI
> for this new instruction.
>
> Thanks to those who commented last time, since then I have removed my
> answered questions and unpopular alternatives but you can find them
> here
>
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
>
> Let me try one more with a wider cc list, and then we'll get something
> merged. Any questions or counter-opinions are welcome.
>
> System Call Vectored (scv) ABI
> ==============================
>
> The scv instruction is introduced with POWER9 / ISA3, it comes with an
> rfscv counter-part. The benefit of these instructions is performance
> (trading slower SRR0/1 with faster LR/CTR registers, and entering the
> kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
> updates. The scv instruction has 128 interrupt entry points (not enough
> to cover the Linux system call space).
>
> The proposal is to assign scv numbers very conservatively and allocate
> them as individual HWCAP features as we add support for more. The zero
> vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
>
> Advertisement
>
> Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
> SIGILL in current environments. Linux has defined a HWCAP2 bit
> PPC_FEATURE2_SCV for SCV support, but does not set it.
>
> When scv instruction support and the scv 0 vector for system calls are
> added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
> should not be used without future HWCAP bits indicating support, which is
> how we will allocate them. (Should unallocated ones generate SIGILL, or
> return -ENOSYS in r3?)
>
> Calling convention
>
> The proposal is for scv 0 to provide the standard Linux system call ABI
> with the following differences from sc convention[1]:
>
> - LR is to be volatile across scv calls. This is necessary because the
> scv instruction clobbers LR. From previous discussion, this should be
> possible to deal with in GCC clobbers and CFI.
>
> - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
> kernel system call exit to avoid restoring the CR register (although
> we probably still would anyway to avoid information leak).
>
> - Error handling: I think the consensus has been to move to using negative
> return value in r3 rather than CR0[SO]=1 to indicate error, which matches
> most other architectures and is closer to a function call.
>
> The number of scratch registers (r9-r12) at kernel entry seems
> sufficient that we don't have any costly spilling, patch is here[2].
>
> [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840.html
My preference would be that it work just like the i386 AT_SYSINFO
where you just replace "int $128" with "call *%%gs:16" and the kernel
provides a stub in the vdso that performs either scv or the old
mechanism with the same calling convention. Then if the kernel doesn't
provide it (because the kernel is too old) libc would have to provide
its own stub that uses the legacy method and matches the calling
convention of the one the kernel is expected to provide.
Note that any libc that actually makes use of the new functionality is
not going to be able to make clobbers conditional on support for it;
branching around different clobbers is going to defeat any gains vs
always just treating anything clobbered by either method as clobbered.
Likewise, it's not useful to have different error return mechanisms
because the caller just has to branch to support both (or the
kernel-provided stub just has to emulate one for it; that could work
if you really want to change the bad existing convention).
Thoughts?
Rich
^ permalink raw reply
* Re: [PATCH v2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'
From: Segher Boessenkool @ 2020-04-15 22:37 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <c9abd91e9bb0b3dd6e3470015e92b98bc2483780.1586942304.git.christophe.leroy@c-s.fr>
Hi!
On Wed, Apr 15, 2020 at 09:25:59AM +0000, Christophe Leroy wrote:
> +#define __put_user_goto(x, ptr, label) \
> + __put_user_nocheck_goto((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)), label)
This line gets too long, can you break it up somehow?
> +#define __put_user_asm_goto(x, addr, label, op) \
> + asm volatile goto( \
> + "1: " op "%U1%X1 %0,%1 # put_user\n" \
> + EX_TABLE(1b, %l2) \
> + : \
> + : "r" (x), "m" (*addr) \
> + : \
> + : label)
Same "%Un" problem as in the other patch. You could use "m<>" here,
but maybe just dropping "%Un" is better.
> +#ifdef __powerpc64__
> +#define __put_user_asm2_goto(x, ptr, label) \
> + __put_user_asm_goto(x, ptr, label, "std")
> +#else /* __powerpc64__ */
> +#define __put_user_asm2_goto(x, addr, label) \
> + asm volatile goto( \
> + "1: stw%U1%X1 %0, %1\n" \
> + "2: stw%U1%X1 %L0, %L1\n" \
> + EX_TABLE(1b, %l2) \
> + EX_TABLE(2b, %l2) \
> + : \
> + : "r" (x), "m" (*addr) \
> + : \
> + : label)
> +#endif /* __powerpc64__ */
Here, you should drop it for sure.
Rest looks fine.
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Re: [PATCH] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()
From: Segher Boessenkool @ 2020-04-15 22:06 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <4fdc2aba6f5e51887d1cd0fee94be0989eada2cd.1586942312.git.christophe.leroy@c-s.fr>
Hi!
On Wed, Apr 15, 2020 at 09:20:26AM +0000, Christophe Leroy wrote:
> At the time being, __put_user()/__get_user() and friends only use
> register indirect with immediate index addressing, with the index
> set to 0. Ex:
>
> lwz reg1, 0(reg2)
This is called a "D-form" instruction, or sometimes "offset addressing".
Don't talk about an "index", it confuses things, because the *other*
kind is called "indexed" already, also in the ISA docs! (X-form, aka
indexed addressing, [reg+reg], where D-form does [reg+imm], and both
forms can do [reg]).
> Give the compiler the opportunity to use other adressing modes
> whenever possible, to get more optimised code.
Great :-)
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -114,7 +114,7 @@ extern long __put_user_bad(void);
> */
> #define __put_user_asm(x, addr, err, op) \
> __asm__ __volatile__( \
> - "1: " op " %1,0(%2) # put_user\n" \
> + "1: " op "%U2%X2 %1,%2 # put_user\n" \
> "2:\n" \
> ".section .fixup,\"ax\"\n" \
> "3: li %0,%3\n" \
> @@ -122,7 +122,7 @@ extern long __put_user_bad(void);
> ".previous\n" \
> EX_TABLE(1b, 3b) \
> : "=r" (err) \
> - : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err))
> + : "r" (x), "m" (*addr), "i" (-EFAULT), "0" (err))
%Un on an "m" operand doesn't do much: you need to make it "m<>" if you
want pre-modify ("update") insns to be generated. (You then will want
to make sure that operand is used in a way GCC can understand; since it
is used only once here, that works fine).
> @@ -130,8 +130,8 @@ extern long __put_user_bad(void);
> #else /* __powerpc64__ */
> #define __put_user_asm2(x, addr, err) \
> __asm__ __volatile__( \
> - "1: stw %1,0(%2)\n" \
> - "2: stw %1+1,4(%2)\n" \
> + "1: stw%U2%X2 %1,%2\n" \
> + "2: stw%U2%X2 %L1,%L2\n" \
> "3:\n" \
> ".section .fixup,\"ax\"\n" \
> "4: li %0,%3\n" \
> @@ -140,7 +140,7 @@ extern long __put_user_bad(void);
> EX_TABLE(1b, 4b) \
> EX_TABLE(2b, 4b) \
> : "=r" (err) \
> - : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err))
> + : "r" (x), "m" (*addr), "i" (-EFAULT), "0" (err))
Here, it doesn't work. You don't want two consecutive update insns in
any case. Easiest is to just not use "m<>", and then, don't use %Un
(which won't do anything, but it is confusing).
Same for the reads.
Rest looks fine, and update should be good with that fixed as said.
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Powerpc Linux 'scv' system call ABI proposal take 2
From: Nicholas Piggin @ 2020-04-15 21:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: libc-dev, libc-alpha, musl
I would like to enable Linux support for the powerpc 'scv' instruction,
as a faster system call instruction.
This requires two things to be defined: Firstly a way to advertise to
userspace that kernel supports scv, and a way to allocate and advertise
support for individual scv vectors. Secondly, a calling convention ABI
for this new instruction.
Thanks to those who commented last time, since then I have removed my
answered questions and unpopular alternatives but you can find them
here
https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
Let me try one more with a wider cc list, and then we'll get something
merged. Any questions or counter-opinions are welcome.
System Call Vectored (scv) ABI
==============================
The scv instruction is introduced with POWER9 / ISA3, it comes with an
rfscv counter-part. The benefit of these instructions is performance
(trading slower SRR0/1 with faster LR/CTR registers, and entering the
kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
updates. The scv instruction has 128 interrupt entry points (not enough
to cover the Linux system call space).
The proposal is to assign scv numbers very conservatively and allocate
them as individual HWCAP features as we add support for more. The zero
vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
Advertisement
Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
SIGILL in current environments. Linux has defined a HWCAP2 bit
PPC_FEATURE2_SCV for SCV support, but does not set it.
When scv instruction support and the scv 0 vector for system calls are
added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
should not be used without future HWCAP bits indicating support, which is
how we will allocate them. (Should unallocated ones generate SIGILL, or
return -ENOSYS in r3?)
Calling convention
The proposal is for scv 0 to provide the standard Linux system call ABI
with the following differences from sc convention[1]:
- LR is to be volatile across scv calls. This is necessary because the
scv instruction clobbers LR. From previous discussion, this should be
possible to deal with in GCC clobbers and CFI.
- CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
kernel system call exit to avoid restoring the CR register (although
we probably still would anyway to avoid information leak).
- Error handling: I think the consensus has been to move to using negative
return value in r3 rather than CR0[SO]=1 to indicate error, which matches
most other architectures and is closer to a function call.
The number of scratch registers (r9-r12) at kernel entry seems
sufficient that we don't have any costly spilling, patch is here[2].
[1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
[2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840.html
^ permalink raw reply
* Re: [PATCH v5 0/6] implement KASLR for powerpc/fsl_booke/64
From: Scott Wood @ 2020-04-15 19:31 UTC (permalink / raw)
To: Jason Yan, mpe, linuxppc-dev, diana.craciun, christophe.leroy,
benh, paulus, npiggin, keescook, kernel-hardening
Cc: dja, linux-kernel, zhaohongjiang
In-Reply-To: <20200330022023.3691-1-yanaijie@huawei.com>
On Mon, 2020-03-30 at 10:20 +0800, Jason Yan wrote:
> This is a try to implement KASLR for Freescale BookE64 which is based on
> my earlier implementation for Freescale BookE32:
>
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=131718&state=*
>
> The implementation for Freescale BookE64 is similar as BookE32. One
> difference is that Freescale BookE64 set up a TLB mapping of 1G during
> booting. Another difference is that ppc64 needs the kernel to be
> 64K-aligned. So we can randomize the kernel in this 1G mapping and make
> it 64K-aligned. This can save some code to creat another TLB map at
> early boot. The disadvantage is that we only have about 1G/64K = 16384
> slots to put the kernel in.
>
> KERNELBASE
>
> 64K |--> kernel <--|
> | | |
> +--+--+--+ +--+--+--+--+--+--+--+--+--+ +--+--+
> | | | |....| | | | | | | | | |....| | |
> +--+--+--+ +--+--+--+--+--+--+--+--+--+ +--+--+
> | | 1G
> |-----> offset <-----|
>
> kernstart_virt_addr
>
> I'm not sure if the slot numbers is enough or the design has any
> defects. If you have some better ideas, I would be happy to hear that.
>
> Thank you all.
>
> v4->v5:
> Fix "-Werror=maybe-uninitialized" compile error.
> Fix typo "similar as" -> "similar to".
> v3->v4:
> Do not define __kaslr_offset as a fixed symbol. Reference __run_at_load
> and
> __kaslr_offset by symbol instead of magic offsets.
> Use IS_ENABLED(CONFIG_PPC32) instead of #ifdef CONFIG_PPC32.
> Change kaslr-booke32 to kaslr-booke in index.rst
> Switch some instructions to 64-bit.
> v2->v3:
> Fix build error when KASLR is disabled.
> v1->v2:
> Add __kaslr_offset for the secondary cpu boot up.
>
> Jason Yan (6):
> powerpc/fsl_booke/kaslr: refactor kaslr_legal_offset() and
> kaslr_early_init()
> powerpc/fsl_booke/64: introduce reloc_kernel_entry() helper
> powerpc/fsl_booke/64: implement KASLR for fsl_booke64
> powerpc/fsl_booke/64: do not clear the BSS for the second pass
> powerpc/fsl_booke/64: clear the original kernel if randomized
> powerpc/fsl_booke/kaslr: rename kaslr-booke32.rst to kaslr-booke.rst
> and add 64bit part
>
> Documentation/powerpc/index.rst | 2 +-
> .../{kaslr-booke32.rst => kaslr-booke.rst} | 35 ++++++-
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/kernel/exceptions-64e.S | 23 +++++
> arch/powerpc/kernel/head_64.S | 13 +++
> arch/powerpc/kernel/setup_64.c | 3 +
> arch/powerpc/mm/mmu_decl.h | 23 +++--
> arch/powerpc/mm/nohash/kaslr_booke.c | 91 +++++++++++++------
> 8 files changed, 147 insertions(+), 45 deletions(-)
> rename Documentation/powerpc/{kaslr-booke32.rst => kaslr-booke.rst} (59%)
>
Acked-by: Scott Wood <oss@buserror.net>
-Scott
^ permalink raw reply
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
From: Scott Wood @ 2020-04-15 19:27 UTC (permalink / raw)
To: Christophe Leroy, Wang Wenhu, gregkh, linux-kernel, linuxppc-dev; +Cc: kernel
In-Reply-To: <37b6b890-e537-7424-6b26-04565681f40a@c-s.fr>
On Wed, 2020-04-15 at 18:52 +0200, Christophe Leroy wrote:
>
> Le 15/04/2020 à 17:24, Wang Wenhu a écrit :
> > +
> > + if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
>
> I'd prefer
> if (uiomem - info->mem >= MAX_UIO_MAPS) {
>
> > + dev_warn(&pdev->dev, "more than %d uio-maps for
> > device.\n",
> > + MAX_UIO_MAPS);
> > + break;
> > + }
> > + }
> > +
> > + while (uiomem < &info->mem[MAX_UIO_MAPS]) {
>
> I'd prefer
>
> while (uiomem - info->mem < MAX_UIO_MAPS) {
>
I wouldn't. You're turning a simple comparison into a division and a
comparison (if the compiler doesn't optimize it back into the original form),
and making it less clear in the process.
Of course, working with array indices to begin with instead of incrementing a
pointer would be more idiomatic.
> > + uiomem->size = 0;
> > + ++uiomem;
> > + }
> > +
> > + if (info->mem[0].size == 0) {
>
> Is there any point in doing all the clearing loop above if it's to bail
> out here ?
>
> Wouldn't it be cleaner to do the test above the clearing loop, by just
> checking whether uiomem is still equal to info->mem ?
There's no point doing the clearing at all, since the array was allocated with
kzalloc().
> > + dev_err(&pdev->dev, "error no valid uio-map configured\n");
> > + ret = -EINVAL;
> > + goto err_info_free_internel;
> > + }
> > +
> > + info->version = "0.1.0";
>
> Could you define some DRIVER_VERSION in the top of the file next to
> DRIVER_NAME instead of hard coding in the middle on a function ?
That's what v1 had, and Greg KH said to remove it. I'm guessing that he
thought it was the common-but-pointless practice of having the driver print a
version number that never gets updated, rather than something the UIO API
(unfortunately, compared to a feature query interface) expects. That said,
I'm not sure what the value is of making it a macro since it should only be
used once, that use is self documenting, it isn't tunable, etc. Though if
this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro
again, it should be UIO_VERSION, not DRIVER_VERSION).
Does this really need a three-part version scheme? What's wrong with a
version of "1", to be changed to "2" in the hopefully-unlikely event that the
userspace API changes? Assuming UIO is used for this at all, which doesn't
seem like a great fit to me.
-Scott
^ permalink raw reply
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
From: Scott Wood @ 2020-04-15 19:26 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, christophe.leroy, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200415152442.122873-6-wenhu.wang@vivo.com>
On Wed, 2020-04-15 at 08:24 -0700, Wang Wenhu wrote:
> +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> + { .compatible = "uio,fsl,p2020-l2-cache-controller", },
> + { .compatible = "uio,fsl,p2010-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1020-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1011-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1013-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1022-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1021-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1012-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1025-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1016-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1024-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1015-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1010-l2-cache-controller", },
> + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", },
> + {},
> +};
NACK
The device tree describes the hardware, not what driver you want to bind the
hardware to, or how you want to allocate the resources. And even if defining
nodes for sram allocation were the right way to go, why do you have a separate
compatible for each chip when you're just describing software configuration?
Instead, have module parameters that take the sizes and alignments you'd like
to allocate and expose to userspace. Better still would be some sort of
dynamic allocation (e.g. open a fd, ioctl to set the requested size/alignment,
if it succeeds you can mmap it, and when the fd is closed the region is
freed).
-Scott
^ permalink raw reply
* Re: [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable
From: Scott Wood @ 2020-04-15 18:53 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, christophe.leroy, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200415152442.122873-2-wenhu.wang@vivo.com>
On Wed, 2020-04-15 at 08:24 -0700, Wang Wenhu wrote:
> Enable FSL_85XX_CACHE_SRAM selection. On e500 platforms, the cache
> could be configured and used as a piece of SRAM which is hignly
> friendly for some user level application performances.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
> ---
> Changes since v1:
> * None
> ---
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig.cputype | 5 +++--
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig
> b/arch/powerpc/platforms/85xx/Kconfig
> index fa3d29dcb57e..6debb4f1b9cc 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -17,7 +17,7 @@ if FSL_SOC_BOOKE
> if PPC32
>
> config FSL_85XX_CACHE_SRAM
> - bool
> + bool "Freescale 85xx Cache-Sram"
> select PPC_LIB_RHEAP
> help
> When selected, this option enables cache-sram support
NACK
As discussed before, the driver that uses this API should "select" this
symbol.
-Scott
^ permalink raw reply
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
From: Christophe Leroy @ 2020-04-15 16:52 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200415152442.122873-6-wenhu.wang@vivo.com>
Le 15/04/2020 à 17:24, Wang Wenhu a écrit :
> A driver for freescale 85xx platforms to access the Cache-Sram form
> user level. This is extremely helpful for some user-space applications
> that require high performance memory accesses.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
> ---
> Changes since v1:
> * Addressed comments of Greg K-H
> * Moved kfree(info->name) into uio_info_free_internal()
> ---
> drivers/uio/Kconfig | 8 ++
> drivers/uio/Makefile | 1 +
> drivers/uio/uio_fsl_85xx_cache_sram.c | 182 ++++++++++++++++++++++++++
> 3 files changed, 191 insertions(+)
> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
>
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 202ee81cfc2b..afd38ec13de0 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -105,6 +105,14 @@ config UIO_NETX
> To compile this driver as a module, choose M here; the module
> will be called uio_netx.
>
> +config UIO_FSL_85XX_CACHE_SRAM
> + tristate "Freescale 85xx Cache-Sram driver"
> + depends on FSL_85XX_CACHE_SRAM
Is there any point having FSL_85XX_CACHE_SRAM without this ?
Should it be the other way round, leave FSL_85XX_CACHE_SRAM unselectable
by user, and this driver select FSL_85XX_CACHE_SRAM instead of depending
on it ?
> + help
> + Generic driver for accessing the Cache-Sram form user level. This
> + is extremely helpful for some user-space applications that require
> + high performance memory accesses.
> +
> config UIO_FSL_ELBC_GPCM
> tristate "eLBC/GPCM driver"
> depends on FSL_LBC
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index c285dd2a4539..be2056cffc21 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o
> obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
> obj-$(CONFIG_UIO_MF624) += uio_mf624.o
> obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o
> +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o
> obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o
> diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c
> new file mode 100644
> index 000000000000..fb6903fdaddb
> --- /dev/null
> +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
> @@ -0,0 +1,182 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
> + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com>
> + * All rights reserved.
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/uio_driver.h>
> +#include <linux/stringify.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <asm/fsl_85xx_cache_sram.h>
> +
> +#define DRIVER_NAME "uio_fsl_85xx_cache_sram"
> +#define UIO_NAME "uio_cache_sram"
> +
> +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> + { .compatible = "uio,fsl,p2020-l2-cache-controller", },
> + { .compatible = "uio,fsl,p2010-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1020-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1011-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1013-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1022-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1021-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1012-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1025-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1016-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1024-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1015-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1010-l2-cache-controller", },
> + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", },
> + {},
> +};
> +
> +static void uio_info_free_internal(struct uio_info *info)
> +{
> + struct uio_mem *uiomem = &info->mem[0];
> +
> + while (uiomem < &info->mem[MAX_UIO_MAPS]) {
> + if (uiomem->size) {
> + mpc85xx_cache_sram_free(uiomem->internal_addr);
> + kfree(uiomem->name);
> + }
> + uiomem++;
> + }
> +
> + kfree(info->name);
> +}
> +
> +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev)
> +{
> + struct device_node *parent = pdev->dev.of_node;
> + struct device_node *node = NULL;
> + struct uio_info *info;
> + struct uio_mem *uiomem;
> + const char *dt_name;
> + u32 mem_size;
> + u32 align;
Align is not used outside of the for loop, it should be declared in the
loop block.
> + void *virt;
Same for virt
> + phys_addr_t phys;
Same for phys
> + int ret = -ENODEV;
It looks like this init value is unneeded, you should leave 'ret'
uninitialised (unless I missed some way out and you get a warning).
> +
> + /* alloc uio_info for one device */
> + info = kzalloc(sizeof(*info), GFP_KERNEL);
> + if (!info) {
> + ret = -ENOMEM;
> + goto err_out;
Nothing special is done at err_out, you should instead do:
if (!info)
return -ENOMEM;
> + }
> +
> + /* get optional uio name */
> + if (of_property_read_string(parent, "uio_name", &dt_name))
> + dt_name = UIO_NAME;
> +
> + info->name = kstrdup(dt_name, GFP_KERNEL);
> + if (!info->name) {
> + ret = -ENOMEM;
> + goto err_info_free;
> + }
> +
> + uiomem = &info->mem[0];
I'd prefer
uiomem = info->mem;
> + for_each_child_of_node(parent, node) {
> + ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
> + if (ret) {
> + ret = -EINVAL;
> + goto err_info_free_internel;
> + }
> +
> + if (mem_size == 0) {
> + dev_err(&pdev->dev, "cache-mem-size should not be 0\n");
> + ret = -EINVAL;
> + goto err_info_free_internel;
> + }
> +
> + align = 2;
> + while (align < mem_size)
> + align *= 2;
I think ilog2() or one of it friends should be used here, maybe
roundup_pow_of_two()
> + virt = mpc85xx_cache_sram_alloc(mem_size, &phys, align);
> + if (!virt) {
> + /* mpc85xx_cache_sram_alloc to define the cause */
> + ret = -EINVAL;
Should it be -ENOMEM like any allocation failure ?
> + goto err_info_free_internel;
> + }
> +
> + uiomem->memtype = UIO_MEM_PHYS;
> + uiomem->addr = phys;
> + uiomem->size = mem_size;
> + uiomem->name = kstrdup(node->name, GFP_KERNEL);;
> + uiomem->internal_addr = virt;
> + ++uiomem;
Usually people use
uiomem++;
> +
> + if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
I'd prefer
if (uiomem - info->mem >= MAX_UIO_MAPS) {
> + dev_warn(&pdev->dev, "more than %d uio-maps for device.\n",
> + MAX_UIO_MAPS);
> + break;
> + }
> + }
> +
> + while (uiomem < &info->mem[MAX_UIO_MAPS]) {
I'd prefer
while (uiomem - info->mem < MAX_UIO_MAPS) {
> + uiomem->size = 0;
> + ++uiomem;
> + }
> +
> + if (info->mem[0].size == 0) {
Is there any point in doing all the clearing loop above if it's to bail
out here ?
Wouldn't it be cleaner to do the test above the clearing loop, by just
checking whether uiomem is still equal to info->mem ?
> + dev_err(&pdev->dev, "error no valid uio-map configured\n");
> + ret = -EINVAL;
> + goto err_info_free_internel;
> + }
> +
> + info->version = "0.1.0";
Could you define some DRIVER_VERSION in the top of the file next to
DRIVER_NAME instead of hard coding in the middle on a function ?
> +
> + /* register uio device */
> + if (uio_register_device(&pdev->dev, info)) {
> + dev_err(&pdev->dev, "uio registration failed\n");
> + ret = -ENODEV;
> + goto err_info_free_internel;
> + }
> +
> + platform_set_drvdata(pdev, info);
> +
> + return 0;
> +err_info_free_internel:
Do you mean 'internal' instead of 'internel' ?
> + uio_info_free_internal(info);
> +err_info_free:
> + kfree(info);
> +err_out:
> + return ret;
> +}
> +
> +static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev)
> +{
> + struct uio_info *info = platform_get_drvdata(pdev);
> +
> + uio_unregister_device(info);
> +
> + uio_info_free_internal(info);
> +
> + kfree(info);
> +
> + return 0;
> +}
> +
> +static struct platform_driver uio_fsl_85xx_cache_sram = {
> + .probe = uio_fsl_85xx_cache_sram_probe,
> + .remove = uio_fsl_85xx_cache_sram_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .owner = THIS_MODULE,
> + .of_match_table = uio_mpc85xx_l2ctlr_of_match,
> + },
> +};
> +
> +module_platform_driver(uio_fsl_85xx_cache_sram);
> +
> +MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>");
> +MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> +MODULE_LICENSE("GPL v2");
>
Christophe
^ permalink raw reply
* Re: [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable
From: Christophe Leroy @ 2020-04-15 16:29 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200415152442.122873-2-wenhu.wang@vivo.com>
Le 15/04/2020 à 17:24, Wang Wenhu a écrit :
> Enable FSL_85XX_CACHE_SRAM selection. On e500 platforms, the cache
> could be configured and used as a piece of SRAM which is hignly
> friendly for some user level application performances.
It looks like following patches are fixing errors generated by selecting
FSL_85XX_CACHE_SRAM.
So this patch should go after the patches which fixes the errors, ie it
should be patch 4 in the series.
Christophe
^ permalink raw reply
* Re: [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable
From: Christophe Leroy @ 2020-04-15 16:26 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200415152442.122873-2-wenhu.wang@vivo.com>
Le 15/04/2020 à 17:24, Wang Wenhu a écrit :
> Enable FSL_85XX_CACHE_SRAM selection. On e500 platforms, the cache
> could be configured and used as a piece of SRAM which is hignly
> friendly for some user level application performances.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
> ---
> Changes since v1:
> * None
> ---
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig.cputype | 5 +++--
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index fa3d29dcb57e..6debb4f1b9cc 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -17,7 +17,7 @@ if FSL_SOC_BOOKE
> if PPC32
>
> config FSL_85XX_CACHE_SRAM
> - bool
> + bool "Freescale 85xx Cache-Sram"
> select PPC_LIB_RHEAP
> help
> When selected, this option enables cache-sram support
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 0c3c1902135c..1921e9a573e8 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> config PPC32
> - bool
> + bool "32-bit kernel"
Why make that user selectable ?
Either a kernel is 64-bit or it is 32-bit. So having PPC64 user
selectable is all we need.
And what is the link between this change and the description in the log ?
> default y if !PPC64
> select KASAN_VMALLOC if KASAN && MODULES
>
> @@ -15,6 +15,7 @@ config PPC_BOOK3S_32
> bool
>
> menu "Processor support"
> +
Why adding this space ?
> choice
> prompt "Processor Type"
> depends on PPC32
> @@ -211,9 +212,9 @@ config PPC_BOOK3E
> depends on PPC_BOOK3E_64
>
> config E500
> + bool "e500 Support"
> select FSL_EMB_PERFMON
> select PPC_FSL_BOOK3E
> - bool
Why make this user-selectable ? This is already selected by the
processors requiring it, ie 8500, e5500 and e6500.
Is there any other case where we need E500 ?
And again, what's the link between this change and the description in
the log ?
>
> config PPC_E500MC
> bool "e500mc Support"
>
Christophe
^ permalink raw reply
* Re: [RFC PATCH 3/3] powerpc/lib: Use a temporary mm for code patching
From: Christopher M Riedl @ 2020-04-15 16:24 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <ee1c177c-a751-29c3-2a36-0d35aa891741@c-s.fr>
> On April 15, 2020 3:45 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>
> Le 15/04/2020 à 07:11, Christopher M Riedl a écrit :
> >> On March 24, 2020 11:25 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> >>
> >>
> >> Le 23/03/2020 à 05:52, Christopher M. Riedl a écrit :
> >>> Currently, code patching a STRICT_KERNEL_RWX exposes the temporary
> >>> mappings to other CPUs. These mappings should be kept local to the CPU
> >>> doing the patching. Use the pre-initialized temporary mm and patching
> >>> address for this purpose. Also add a check after patching to ensure the
> >>> patch succeeded.
> >>>
> >>> Based on x86 implementation:
> >>>
> >>> commit b3fd8e83ada0
> >>> ("x86/alternatives: Use temporary mm for text poking")
> >>>
> >>> Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
> >>> ---
> >>> arch/powerpc/lib/code-patching.c | 128 ++++++++++++++-----------------
> >>> 1 file changed, 57 insertions(+), 71 deletions(-)
> >>>
> >>> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> >>> index 18b88ecfc5a8..f156132e8975 100644
> >>> --- a/arch/powerpc/lib/code-patching.c
> >>> +++ b/arch/powerpc/lib/code-patching.c
> >>> @@ -19,6 +19,7 @@
> >>> #include <asm/page.h>
> >>> #include <asm/code-patching.h>
> >>> #include <asm/setup.h>
> >>> +#include <asm/mmu_context.h>
> >>>
> >>> static int __patch_instruction(unsigned int *exec_addr, unsigned int instr,
> >>> unsigned int *patch_addr)
> >>> @@ -65,99 +66,79 @@ void __init poking_init(void)
> >>> pte_unmap_unlock(ptep, ptl);
> >>> }
> >>>
> >>> -static DEFINE_PER_CPU(struct vm_struct *, text_poke_area);
> >>> -
> >>> -static int text_area_cpu_up(unsigned int cpu)
> >>> -{
> >>> - struct vm_struct *area;
> >>> -
> >>> - area = get_vm_area(PAGE_SIZE, VM_ALLOC);
> >>> - if (!area) {
> >>> - WARN_ONCE(1, "Failed to create text area for cpu %d\n",
> >>> - cpu);
> >>> - return -1;
> >>> - }
> >>> - this_cpu_write(text_poke_area, area);
> >>> -
> >>> - return 0;
> >>> -}
> >>> -
> >>> -static int text_area_cpu_down(unsigned int cpu)
> >>> -{
> >>> - free_vm_area(this_cpu_read(text_poke_area));
> >>> - return 0;
> >>> -}
> >>> -
> >>> -/*
> >>> - * Run as a late init call. This allows all the boot time patching to be done
> >>> - * simply by patching the code, and then we're called here prior to
> >>> - * mark_rodata_ro(), which happens after all init calls are run. Although
> >>> - * BUG_ON() is rude, in this case it should only happen if ENOMEM, and we judge
> >>> - * it as being preferable to a kernel that will crash later when someone tries
> >>> - * to use patch_instruction().
> >>> - */
> >>> -static int __init setup_text_poke_area(void)
> >>> -{
> >>> - BUG_ON(!cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
> >>> - "powerpc/text_poke:online", text_area_cpu_up,
> >>> - text_area_cpu_down));
> >>> -
> >>> - return 0;
> >>> -}
> >>> -late_initcall(setup_text_poke_area);
> >>> +struct patch_mapping {
> >>> + spinlock_t *ptl; /* for protecting pte table */
> >>> + struct temp_mm temp_mm;
> >>> +};
> >>>
> >>> /*
> >>> * This can be called for kernel text or a module.
> >>> */
> >>> -static int map_patch_area(void *addr, unsigned long text_poke_addr)
> >>> +static int map_patch(const void *addr, struct patch_mapping *patch_mapping)
> >>
> >> Why change the name ?
> >>
> >
> > It's not really an "area" anymore.
> >
> >>> {
> >>> - unsigned long pfn;
> >>> - int err;
> >>> + struct page *page;
> >>> + pte_t pte, *ptep;
> >>> + pgprot_t pgprot;
> >>>
> >>> if (is_vmalloc_addr(addr))
> >>> - pfn = vmalloc_to_pfn(addr);
> >>> + page = vmalloc_to_page(addr);
> >>> else
> >>> - pfn = __pa_symbol(addr) >> PAGE_SHIFT;
> >>> + page = virt_to_page(addr);
> >>>
> >>> - err = map_kernel_page(text_poke_addr, (pfn << PAGE_SHIFT), PAGE_KERNEL);
> >>> + if (radix_enabled())
> >>> + pgprot = __pgprot(pgprot_val(PAGE_KERNEL));
> >>> + else
> >>> + pgprot = PAGE_SHARED;
> >>
> >> Can you explain the difference between radix and non radix ?
> >>
> >> Why PAGE_KERNEL for a page that is mapped in userspace ?
> >>
> >> Why do you need to do __pgprot(pgprot_val(PAGE_KERNEL)) instead of just
> >> using PAGE_KERNEL ?
> >>
> >
> > On hash there is a manual check which prevents setting _PAGE_PRIVILEGED for
> > kernel to userspace access in __hash_page - hence we cannot access the mapping
> > if the page is mapped PAGE_KERNEL on hash. However, I would like to use
> > PAGE_KERNEL here as well and am working on understanding why this check is
> > done in hash and if this can change. On radix this works just fine.
> >
> > The page is mapped PAGE_KERNEL because the address is technically a userspace
> > address - but only to keep the mapping local to this CPU doing the patching.
> > PAGE_KERNEL makes it clear both in intent and protection that this is a kernel
> > mapping.
> >
> > I think the correct way is pgprot_val(PAGE_KERNEL) since PAGE_KERNEL is defined
> > as:
> >
> > #define PAGE_KERNEL __pgprot(_PAGE_BASE | _PAGE_KERNEL_RW)
> >
> > and __pgprot() is defined as:
> >
> > typedef struct { unsigned long pgprot; } pgprot_t;
> > #define pgprot_val(x) ((x).pgprot)
> > #define __pgprot(x) ((pgprot_t) { (x) })
>
>
> Yes, so:
> pgprot_val(__pgprot(x)) == x
>
>
> You do:
>
> pgprot = __pgprot(pgprot_val(PAGE_KERNEL));
>
> Which is:
>
> pgprot = __pgprot(pgprot_val(__pgprot(_PAGE_BASE | _PAGE_KERNEL_RW)));
>
> Which is equivalent to:
>
> pgprot = __pgprot(_PAGE_BASE | _PAGE_KERNEL_RW);
>
> So at the end it should simply be:
>
> pgprot = PAGE_KERNEL;
>
Yes you're correct. Picking this up in the next spin.
>
>
>
> Christophe
^ permalink raw reply
* Re: [RFC PATCH] powerpc/lib: Fixing use a temporary mm for code patching
From: Christopher M Riedl @ 2020-04-15 16:22 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <badfcf58-9fcb-6189-c9db-e8429f88799e@c-s.fr>
> On April 15, 2020 4:12 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>
> Le 15/04/2020 à 07:16, Christopher M Riedl a écrit :
> >> On March 26, 2020 9:42 AM Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> >>
> >>
> >> This patch fixes the RFC series identified below.
> >> It fixes three points:
> >> - Failure with CONFIG_PPC_KUAP
> >> - Failure to write do to lack of DIRTY bit set on the 8xx
> >> - Inadequaly complex WARN post verification
> >>
> >> However, it has an impact on the CPU load. Here is the time
> >> needed on an 8xx to run the ftrace selftests without and
> >> with this series:
> >> - Without CONFIG_STRICT_KERNEL_RWX ==> 38 seconds
> >> - With CONFIG_STRICT_KERNEL_RWX ==> 40 seconds
> >> - With CONFIG_STRICT_KERNEL_RWX + this series ==> 43 seconds
> >>
> >> Link: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166003
> >> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> >> ---
> >> arch/powerpc/lib/code-patching.c | 5 ++++-
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> >> index f156132e8975..4ccff427592e 100644
> >> --- a/arch/powerpc/lib/code-patching.c
> >> +++ b/arch/powerpc/lib/code-patching.c
> >> @@ -97,6 +97,7 @@ static int map_patch(const void *addr, struct patch_mapping *patch_mapping)
> >> }
> >>
> >> pte = mk_pte(page, pgprot);
> >> + pte = pte_mkdirty(pte);
> >> set_pte_at(patching_mm, patching_addr, ptep, pte);
> >>
> >> init_temp_mm(&patch_mapping->temp_mm, patching_mm);
> >> @@ -168,7 +169,9 @@ static int do_patch_instruction(unsigned int *addr, unsigned int instr)
> >> (offset_in_page((unsigned long)addr) /
> >> sizeof(unsigned int));
> >>
> >> + allow_write_to_user(patch_addr, sizeof(instr));
> >> __patch_instruction(addr, instr, patch_addr);
> >> + prevent_write_to_user(patch_addr, sizeof(instr));
> >>
> >
> > On radix we can map the page with PAGE_KERNEL protection which ends up
> > setting EAA[0] in the radix PTE. This means the KUAP (AMR) protection is
> > ignored (ISA v3.0b Fig. 35) since we are accessing the page from MSR[PR]=0.
> >
> > Can we employ a similar approach on the 8xx? I would prefer *not* to wrap
> > the __patch_instruction() with the allow_/prevent_write_to_user() KUAP things
> > because this is a temporary kernel mapping which really isn't userspace in
> > the usual sense.
>
> On the 8xx, that's pretty different.
>
> The PTE doesn't control whether a page is user page or a kernel page.
> The only thing that is set in the PTE is whether a page is linked to a
> given PID or not.
> PAGE_KERNEL tells that the page can be addressed with any PID.
>
> The user access right is given by a kind of zone, which is in the PGD
> entry. Every pages above PAGE_OFFSET are defined as belonging to zone 0.
> Every pages below PAGE_OFFSET are defined as belonging to zone 1.
>
> By default, zone 0 can only be accessed by kernel, and zone 1 can only
> be accessed by user. When kernel wants to access zone 1, it temporarily
> changes properties of zone 1 to allow both kernel and user accesses.
>
> So, if your mapping is below PAGE_OFFSET, it is in zone 1 and kernel
> must unlock it to access it.
>
>
> And this is more or less the same on hash/32. This is managed by segment
> registers. One segment register corresponds to a 256Mbytes area. Every
> pages below PAGE_OFFSET can only be read by default by kernel. Only user
> can write if the PTE allows it. When the kernel needs to write at an
> address below PAGE_OFFSET, it must change the segment properties in the
> corresponding segment register.
>
> So, for both cases, if we want to have it local to a task while still
> allowing kernel access, it means we have to define a new special area
> between TASK_SIZE and PAGE_OFFSET which belongs to kernel zone.
>
> That looks complex to me for a small benefit, especially as 8xx is not
> SMP and neither are most of the hash/32 targets.
>
Agreed. So I guess the solution is to differentiate between radix/non-radix
and use PAGE_SHARED for non-radix along with the KUAP functions when KUAP
is enabled. Hmm, I need to think about this some more, especially if it's
acceptable to temporarily map kernel text as PAGE_SHARED for patching. Do
you see any obvious problems on 8xx and hash/32 w/ using PAGE_SHARED?
I don't necessarily want to drop the local mm patching idea for non-radix
platforms since that means we would have to maintain two implementations.
> Christophe
^ permalink raw reply
* Re: Linux-next POWER9 NULL pointer NIP since 1st Apr.
From: Qian Cai @ 2020-04-15 15:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Steven Rostedt, linuxppc-dev, LKML, Nicholas Piggin
In-Reply-To: <06A2EA93-B730-4DB1-819F-D27E7032F0B3@lca.pw>
> On Apr 10, 2020, at 3:20 PM, Qian Cai <cai@lca.pw> wrote:
>
>
>
>> On Apr 9, 2020, at 10:14 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>
>> On Thu, 9 Apr 2020 06:06:35 -0400
>> Qian Cai <cai@lca.pw> wrote:
>>
>>>>> I’ll go to bisect some more but it is going to take a while.
>>>>>
>>>>> $ git log --oneline 4c205c84e249..8e99cf91b99b
>>>>> 8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in atomic
>>>>> 2ab2a0924b99 tracing: Add documentation on set_ftrace_notrace_pid and set_event_notrace_pid
>>>>> ebed9628f5c2 selftests/ftrace: Add test to test new set_event_notrace_pid file
>>>>> ed8839e072b8 selftests/ftrace: Add test to test new set_ftrace_notrace_pid file
>>>>> 276836260301 tracing: Create set_event_notrace_pid to not trace tasks
>>>>
>>>>> b3b1e6ededa4 ftrace: Create set_ftrace_notrace_pid to not trace tasks
>>>>> 717e3f5ebc82 ftrace: Make function trace pid filtering a bit more exact
>>>>
>>>> If it is affecting function tracing, it is probably one of the above two
>>>> commits.
>>>
>>> OK, it was narrowed down to one of those messed with mcount here,
>>
>> Thing is, nothing here touches mcount.
>
> Yes, you are right. I went back to test the commit just before the 5.7-trace merge request,
> I did reproduce there. The thing is that this bastard could take more 6-hour to happen,
> so my previous attempt did not wait long enough. Back to the square one…
OK, I starts to test all commits up to 12 hours. The progess on far is,
BAD: v5.6-rc1
GOOD: v5.5
GOOD: 153b5c566d30 Merge tag 'microblaze-v5.6-rc1' of git://git.monstr.eu/linux-2.6-microblaze
The next step I’ll be testing,
71c3a888cbca Merge tag 'powerpc-5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
IF that is BAD, the merge request is the culprit. I can see a few commits are more related that others.
5290ae2b8e5f powerpc/64: Use {SAVE,REST}_NVGPRS macros
ed0bc98f8cbe powerpc/64s: Reimplement power4_idle code in C
Does it ring any bell yet?
^ permalink raw reply
* Re: [PATCH] lib/mpi: Fix building for powerpc with clang
From: Herbert Xu @ 2020-04-14 13:57 UTC (permalink / raw)
To: Nathan Chancellor
Cc: kbuild test robot, linux-kernel, clang-built-linux,
Paul Mackerras, linux-crypto, linuxppc-dev
In-Reply-To: <20200413195041.24064-1-natechancellor@gmail.com>
On Mon, Apr 13, 2020 at 12:50:42PM -0700, Nathan Chancellor wrote:
> 0day reports over and over on an powerpc randconfig with clang:
>
> lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
> inline asm context requiring an l-value: remove the cast or build with
> -fheinous-gnu-extensions
>
> Remove the superfluous casts, which have been done previously for x86
> and arm32 in commit dea632cadd12 ("lib/mpi: fix build with clang") and
> commit 7b7c1df2883d ("lib/mpi/longlong.h: fix building with 32-bit
> x86").
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Link: https://github.com/ClangBuiltLinux/linux/issues/991
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2, 4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
From: Wang Wenhu @ 2020-04-15 15:24 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200415152442.122873-1-wenhu.wang@vivo.com>
Include "linux/of_address.h" to fix the compile error for
mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^~~~~~~~
pci_iomap
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^
cc1: all warnings being treated as errors
scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed
make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* None
---
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
index 2d0af0c517bb..7533572492f0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -10,6 +10,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of_platform.h>
+#include <linux/of_address.h>
#include <asm/io.h>
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
^ permalink raw reply related
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