Messages in this thread | | | Date | Fri, 16 Jul 2021 20:57:57 +0800 | From | Jisheng Zhang <> | Subject | Re: [GIT PULL] RISC-V Patches for the 5.14 Merge Window, Part 1 |
| |
On Thu, 15 Jul 2021 09:11:14 +0200 Alex Ghiti <alex@ghiti.fr> wrote:
> Hi Palmer, > > Le 11/07/2021 à 20:45, Palmer Dabbelt a écrit : > > On Fri, 09 Jul 2021 12:58:10 PDT (-0700), alex@ghiti.fr wrote: > >> > >> > >> Le 9/07/2021 à 16:53, Palmer Dabbelt a écrit : > >>> The following changes since commit > >>> 8a4102a0cf07cc76a18f373f6b49485258cc6af4: > >>> > >>> riscv: mm: Fix W+X mappings at boot (2021-06-01 21:15:09 -0700) > >>> > >>> are available in the Git repository at: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git > >>> tags/riscv-for-linus-5.14-mw0 > >>> > >>> for you to fetch changes up to 1958e5aef5098e28b7d6e6a2972649901ebecace: > >>> > >>> riscv: xip: Fix duplicate included asm/pgtable.h (2021-07-06 > >>> 16:17:40 -0700) > >>> > >>> ---------------------------------------------------------------- > >>> RISC-V Patches for the 5.14 Merge Window, Part 1 > >>> > >>> In addition to We have a handful of new features for 5.14: > >>> > >>> * Support for transparent huge pages. > >>> * Support for generic PCI resources mapping. > >>> * Support for the mem= kernel parameter. > >>> * Support for KFENCE. > >>> * A handful of fixes to avoid W+X mappings in the kernel. > >>> * Support for VMAP_STACK based overflow detection. > >>> * An optimized copy_{to,from}_user. > >>> ---------------------------------------------------------------- > >>> There are some Kconfig merge conflicts. They should be pretty > >>> straight-forward, but we do have a symbol out of order -- I thought I > >>> had a > >>> script to check for that, but I guess it doesn't work. I just sent > >>> out a patch > >>> to fix it up. > >>> > >>> diff --cc arch/riscv/Kconfig > >>> index 3590eb76000e,469a70bd8da6..d36f3c5029fd > >>> --- a/arch/riscv/Kconfig > >>> +++ b/arch/riscv/Kconfig > >>> @@@ -60,12 -61,11 +61,12 @@@ config RISC > >>> select GENERIC_TIME_VSYSCALL if MMU && 64BIT > >>> select HANDLE_DOMAIN_IRQ > >>> select HAVE_ARCH_AUDITSYSCALL > >>> - select HAVE_ARCH_JUMP_LABEL > >>> - select HAVE_ARCH_JUMP_LABEL_RELATIVE > >>> + select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL > >>> + select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL > >>> select HAVE_ARCH_KASAN if MMU && 64BIT > >>> select HAVE_ARCH_KASAN_VMALLOC if MMU && 64BIT > >>> + select HAVE_ARCH_KFENCE if MMU && 64BIT > >>> - select HAVE_ARCH_KGDB > >>> + select HAVE_ARCH_KGDB if !XIP_KERNEL > >>> select HAVE_ARCH_KGDB_QXFER_PKT > >>> select HAVE_ARCH_MMAP_RND_BITS if MMU > >>> select HAVE_ARCH_SECCOMP_FILTER > >>> @@@ -81,11 -80,9 +82,14 @@@ > >>> select HAVE_GCC_PLUGINS > >>> select HAVE_GENERIC_VDSO if MMU && 64BIT > >>> select HAVE_IRQ_TIME_ACCOUNTING > >>> + select HAVE_KPROBES > >>> + select HAVE_KPROBES_ON_FTRACE > >>> + select HAVE_KRETPROBES > >>> + select HAVE_KPROBES if !XIP_KERNEL > >>> + select HAVE_KPROBES_ON_FTRACE if !XIP_KERNEL > >>> + select HAVE_KRETPROBES if !XIP_KERNEL > >>> + select HAVE_MOVE_PMD > >>> + select HAVE_MOVE_PUD > >>> select HAVE_PCI > >>> select HAVE_PERF_EVENTS > >>> select HAVE_PERF_REGS > >>> @@@ -108,7 -104,7 +112,8 @@@ > >>> select SYSCTL_EXCEPTION_TRACE > >>> select THREAD_INFO_IN_TASK > >>> select UACCESS_MEMCPY if !MMU > >>> + select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT && MMU > >>> + select ZONE_DMA32 if 64BIT > >>> > >>> config ARCH_MMAP_RND_BITS_MIN > >>> default 18 if 64BIT > >>> ---------------------------------------------------------------- > >>> Akira Tsukamoto (1): > >>> riscv: __asm_copy_to-from_user: Optimize unaligned memory > >>> access and pipeline stall > >>> > >>> Alexandre Ghiti (6): > >>> riscv: Remove CONFIG_PHYS_RAM_BASE_FIXED > >>> riscv: Simplify xip and !xip kernel address conversion macros > >> > >> @Palmer: As said in the thread of this patchset multiple times, those 2 > >> patches should not be merged as it assumes that the base DRAM address is > >> always 0x8000_0000 for all rv64 platforms: I don't think it is true, > >> is it? > > > > Sorry, I remember saying something about that but must have missed the > > resposeses. Do you have a pointer to the discussion? If this break > > stuff I'm happy to revert it, which can be done post-rc1. I just need > > to see what's actually broken first, because IIUC this was de-facto how > > things worked already. > > > > Really sorry about my response delay. > > The thing is that removing CONFIG_PHYS_RAM_BASE_FIXED defines > CONFIG_PHYS_RAM_BASE to 0x8000_0000 for all rv64 chips, but I believe > this is implementation specific: for now, this base address was passed > into the device tree, and here it makes this value static. > > This issue with my patch was originally pointed by Jisheng, Geert and Arnd. > > If this is not a problem and you have a pointer to a document that > specifies this, I would be very happy to have the link :) > > Thanks and again sorry about my response delay, >
Hi Alex,
Since the PR has been merged into linux-5.14-rc1, directly reverting seems not a good idea. IMHO, it's better to send patch(es) against current 5.14-rc1 tree. what do you think?
Thanks
| |