1. 22 4月, 2019 9 次提交
    • G
      csky: Reconstruct signal processing · bf241682
      Guo Ren 提交于
      Linux kernel has provided some apis for arch signal's implementation.
      For example:
      	restore_saved_sigmask()
      	set_current_blocked()
      	restore_altstack()
      
      But in last version of csky signal.c didn't use them and some codes are
      confusing, so reconstruct signal.c with reference to riscv's code.
      
      Now csky signal.c implementation are very close to riscv and we can
      get the following benefits:
       - Clear code structure
       - The signal code of riscv and csky can be reviewed together
       - Promoting the unification of arch's signal implementation
      
      Also modified the related code in entry.S
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      bf241682
    • G
      csky: Use in_syscall & forget_syscall instead of r11_sig · f4625ee0
      Guo Ren 提交于
      We could use regs->sr 16-24 bits to detect syscall: VEC_TRAP0 and
      r11_sig is no necessary for current implementation.
      
      In this patch, we implement the in_syscall and forget_syscall which are
      inspired from arm & nds32, but csky pt_regs has no syscall_num element
      and we just set zero to regs->sr's vector-bits-field instead.
      
      For ret_from_fork, current task was forked from parent which is in syscall
      progress and its regs->sr has been already setted with VEC_TRAP0. See:
      arch/csky/kernel/process.c: copy_thread()
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      f4625ee0
    • G
      csky: Add non-uapi asm/ptrace.h namespace · f335b10f
      Guo Ren 提交于
      Move #ifdef __KERNEL__ code in the uapi namespace to non-uapi
      include/asm/ptrace.h namespace and remove #ifdef __KERNEL__ in
      include/asm/ptrace.h. Seperate ptrace.h in uapi and non-uapi is more
      common and clear.
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      Cc: Dmitry V. Levin <ldv@altlinux.org>
      f335b10f
    • J
      csky: mm/fault.c: Remove duplicate header · ce63cd5b
      Jagadeesh Pagadala 提交于
      Remove duplicate header which is included twice.
      Signed-off-by: NJagadeesh Pagadala <jagdsh.linux@gmail.com>
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      ce63cd5b
    • M
      csky: remove redundant generic-y · 1b2707fb
      Masahiro Yamada 提交于
      Since commit 7cbbbb8b ("kbuild: warn redundant generic-y"),
      redundant generic-y is reported. I missed to delete this one.
      
      scripts/Makefile.asm-generic:25: redundant generic-y found in arch/csky/include/asm/Kbuild: ftrace.h
      
      In this case, csky-specific implementation exists in
      arch/csky/include/asm/ftrace.h
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      1b2707fb
    • G
      csky: Update syscall_trace_enter/exit implementation · 2f7932b0
      Guo Ren 提交于
      Previous syscall_trace implementation couldn't support AUDITSYSCALL and
      SYSCALL_TRACEPOINTS. Now we redesign it to support audit_syscall
      and syscall_tracepoints just like other archs'.
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      Cc: Dmitry V. Levin <ldv@altlinux.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      2f7932b0
    • M
      csky: Add perf callchain support · cfa4d93b
      Mao Han 提交于
      This patch add support for perf callchain sampling on csky platform.
      As fp is used to unwind the stack, the program being sampled and the
      C library need to be compiled with -mbacktrace for user callchains,
      kernel callchains require CONFIG_STACKTRACE = y.
      
      Changelog:
       - Coding convention with Christoph's advice for riscv's.
      Signed-off-by: NMao Han <han_mao@c-sky.com>
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      cfa4d93b
    • G
      csky/ftrace: Add dynamic function tracer (include graph tracer) · 28bb030f
      Guo Ren 提交于
      Support dynamic ftrace including dynamic graph tracer. Gcc-csky with -pg
      will produce call site in every function prologue and we can use these
      call site to hook trace function.
      
      gcc with -pg origin call site:
      	push	lr
      	jbsr	_mcount
      	nop32
      	nop32
      
      If the (callee - caller)'s offset is in range of bsr instruction, we'll
      modify code with:
      	push	lr
      	bsr	_mcount
      	nop32
      	nop32
      Else if the (callee - caller)'s offset is out of bsr instrunction, we'll
      modify code with:
      	push	lr
      	movih	r26, ...
      	ori	r26, ...
      	jsr	r26
      
      (r26 is reserved for jsr link reg in csky abiv2 spec.)
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      28bb030f
    • G
      csky: Fixup vdsp&fpu issues in kernel · 3dfc242f
      Guo Ren 提交于
      This fixup is continue to commit 35ff802a (csky: fixup remove
      vdsp implement for kernel.) and in that patch I didn't finish the
      job. We must forbid gcc to generate any vdsp & fpu instructions
      and remove vdsp asm in memmove.S.
      
      eg: For GCC it's -mcpu=ck860 and For AS it's -Wa,-mcpu=ck860fv
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      3dfc242f
  2. 20 4月, 2019 1 次提交
  3. 19 4月, 2019 4 次提交
  4. 18 4月, 2019 2 次提交
    • K
      perf/x86/amd: Add event map for AMD Family 17h · 3fe3331b
      Kim Phillips 提交于
      Family 17h differs from prior families by:
      
       - Does not support an L2 cache miss event
       - It has re-enumerated PMC counters for:
         - L2 cache references
         - front & back end stalled cycles
      
      So we add a new amd_f17h_perfmon_event_map[] so that the generic
      perf event names will resolve to the correct h/w events on
      family 17h and above processors.
      
      Reference sections 2.1.13.3.3 (stalls) and 2.1.13.3.6 (L2):
      
        https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdfSigned-off-by: NKim Phillips <kim.phillips@amd.com>
      Cc: <stable@vger.kernel.org> # v4.9+
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Liška <mliska@suse.cz>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Pu Wen <puwen@hygon.cn>
      Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Fixes: e40ed154 ("perf/x86: Add perf support for AMD family-17h processors")
      [ Improved the formatting a bit. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      3fe3331b
    • B
      x86/mm/KASLR: Fix the size of the direct mapping section · ec393710
      Baoquan He 提交于
      kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate
      the maximum amount of system RAM supported. The size of the direct
      mapping section is obtained from the smaller one of the below two
      values:
      
        (actual system RAM size + padding size) vs (max system RAM size supported)
      
      This calculation is wrong since commit
      
        b83ce5ee ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52").
      
      In it, __PHYSICAL_MASK_SHIFT was changed to be 52, regardless of whether
      the kernel is using 4-level or 5-level page tables. Thus, it will always
      use 4 PB as the maximum amount of system RAM, even in 4-level paging
      mode where it should actually be 64 TB.
      
      Thus, the size of the direct mapping section will always
      be the sum of the actual system RAM size plus the padding size.
      
      Even when the amount of system RAM is 64 TB, the following layout will
      still be used. Obviously KALSR will be weakened significantly.
      
         |____|_______actual RAM_______|_padding_|______the rest_______|
         0            64TB                                            ~120TB
      
      Instead, it should be like this:
      
         |____|_______actual RAM_______|_________the rest______________|
         0            64TB                                            ~120TB
      
      The size of padding region is controlled by
      CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, which is 10 TB by default.
      
      The above issue only exists when
      CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING is set to a non-zero value,
      which is the case when CONFIG_MEMORY_HOTPLUG is enabled. Otherwise,
      using __PHYSICAL_MASK_SHIFT doesn't affect KASLR.
      
      Fix it by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
      
       [ bp: Massage commit message. ]
      
      Fixes: b83ce5ee ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52")
      Signed-off-by: NBaoquan He <bhe@redhat.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NThomas Garnier <thgarnie@google.com>
      Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: frank.ramsay@hpe.com
      Cc: herbert@gondor.apana.org.au
      Cc: kirill@shutemov.name
      Cc: mike.travis@hpe.com
      Cc: thgarnie@google.com
      Cc: x86-ml <x86@kernel.org>
      Cc: yamada.masahiro@socionext.com
      Link: https://lkml.kernel.org/r/20190417083536.GE7065@MiWiFi-R3L-srv
      ec393710
  5. 17 4月, 2019 1 次提交
  6. 16 4月, 2019 23 次提交