[RESEND PATCH] x86/boot/KASLR: Extend movable_node option for KASLR

The movable_node option is a boot-time switch to make sure the physical NUMA nodes can be hot-added/removed when ACPI table can't be parsed to provide the memory hotplug information. As we all know, there is always one node, called "home node", which can't be movabled and the kernel image resides

Re: [PATCH 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

On Mon, 02 Apr 2018 05:31:22 PDT (-0700), alan...@andestech.com wrote: This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also written, containing perf concepts, arch porting practices and some hints. Changes in v2: - Fix the bug reported by Alex,

Re: [PATCH v2 1/2] perf: riscv: preliminary RISC-V support

This works for cycle and instruction counts. Alex On Mon, Apr 2, 2018 at 5:31 AM, Alan Kao wrote: > > This patch provide a basic PMU, riscv_base_pmu, which supports two > general hardware event, instructions and cycles. Furthermore, this > PMU serves as a reference

Re: [PATCH v4 6/6] coresight: etm4x: Support panic kdump

On Fri, Mar 30, 2018 at 11:15:24AM +0800, Leo Yan wrote: > ETMv4 hardware information and configuration needs to be saved as > metadata; the metadata format should be compatible with 'perf' tool and > finally is used by tracing data decoder. ETMv4 works as tracer per CPU, > we cannot wait for

Re: [PATCH v4 5/6] coresight: Set and clear sink device handler for kdump node

On Fri, Mar 30, 2018 at 11:15:23AM +0800, Leo Yan wrote: > If Coresight path is enabled for specific CPU, the sink device handler > need to be set to kdump node; on the other hand we also need to clear > sink device handler when path is disabled. > > This patch sets sink devices handler for kdump

Re: [PATCH v4 4/6] coresight: tmc: Hook callback for panic kdump

On Fri, Mar 30, 2018 at 11:15:22AM +0800, Leo Yan wrote: > Since Coresight panic kdump functionality has been ready, this patch is > to hook panic callback function for ETB/ETF driver. The driver data > structure has allocated a buffer when the session started, so simply > save tracing data into

Re: [PATCH v4 3/6] coresight: Support panic kdump functionality

On Fri, Mar 30, 2018 at 11:15:21AM +0800, Leo Yan wrote: > After kernel panic happens, Coresight tracing data has much useful info > which can be used for analysis. For example, the trace info from ETB > RAM can be used to check the CPU execution flows before the crash. So > we can save the

Re: [PATCH v3 5/6] Initialize the mapping of KASan shadow memory

On Mon, 2 Apr 2018, Russell King - ARM Linux wrote: > On Mon, Apr 02, 2018 at 02:08:13PM -0400, Nicolas Pitre wrote: > > On Mon, 2 Apr 2018, Abbott Liu wrote: > > > > > index c79b829..20161e2 100644 > > > --- a/arch/arm/kernel/head-common.S > > > +++ b/arch/arm/kernel/head-common.S > > > @@

Re: [PATCH v3 5/6] Initialize the mapping of KASan shadow memory

On Mon, Apr 02, 2018 at 02:08:13PM -0400, Nicolas Pitre wrote: > On Mon, 2 Apr 2018, Abbott Liu wrote: > > > index c79b829..20161e2 100644 > > --- a/arch/arm/kernel/head-common.S > > +++ b/arch/arm/kernel/head-common.S > > @@ -115,6 +115,9 @@ __mmap_switched: > > str r8, [r2]

Re: [PATCH v3 5/6] Initialize the mapping of KASan shadow memory

On Mon, 2 Apr 2018, Abbott Liu wrote: > index c79b829..20161e2 100644 > --- a/arch/arm/kernel/head-common.S > +++ b/arch/arm/kernel/head-common.S > @@ -115,6 +115,9 @@ __mmap_switched: > str r8, [r2]@ Save atags pointer > cmp r3, #0 > strne r10,

Re: [PATCH v4 2/6] doc: Add documentation for Coresight panic kdump

On Fri, Mar 30, 2018 at 11:15:20AM +0800, Leo Yan wrote: > Add detailed documentation for Coresight panic kdump, which contains > the idea for why need Coresight panic kdump and introduce the > implementation of Coresight panic kdump framework; the last section is > to explain what's usage. > >

Re: [PATCH v4 0/6] Coresight: Support panic kdump

Hi Leo, Please see below (and in upcoming patches) my comments related to your latest work. Thanks, Mathieu On Fri, Mar 30, 2018 at 11:15:18AM +0800, Leo Yan wrote: > This patch set is to explore Coresight tracing data for postmortem > debugging. When kernel panic happens, the Coresight panic

[PULL] Documentation for 4.17

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2: Linux 4.16-rc1 (2018-02-11 15:04:29 -0800) are available in the Git repository at: git://git.lwn.net/linux.git tags/docs-4.17 for you to fetch changes up to 86afad7d87f535ebb1a0e978bc32a8c58ac99268:

[PATCH 1/2] Input: mk712: update documentation web link

At the mentioned address there's nothing found. By searching information on the controller chip still can be found, so update the link to the resulting page. Signed-off-by: Martin Kepplinger --- drivers/input/touchscreen/mk712.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 2/2] Documentation: devices.txt: remove the mk712 touchscreen device from the list

The input/touchscreen/mk712.c driver has been rewritten for the common input event system. in 2005. There shouldn't a special device node be created anymore. Signed-off-by: Martin Kepplinger --- Please review this by looking at the driver too. Thanks,

[PATCH v2 2/2] perf: riscv: Add Document for Future Porting Guide

Cc: Nick Hu Cc: Greentime Hu Signed-off-by: Alan Kao --- Documentation/riscv/pmu.txt | 249 1 file changed, 249 insertions(+) create mode 100644 Documentation/riscv/pmu.txt diff

[PATCH v2 1/2] perf: riscv: preliminary RISC-V support

This patch provide a basic PMU, riscv_base_pmu, which supports two general hardware event, instructions and cycles. Furthermore, this PMU serves as a reference implementation to ease the portings in the future. riscv_base_pmu should be able to run on any RISC-V machine that conforms to the

[PATCH 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also written, containing perf concepts, arch porting practices and some hints. Changes in v2: - Fix the bug reported by Alex, which was caused by not sufficient initialization. Check

[PATCH v3 5/6] Initialize the mapping of KASan shadow memory

From: Andrey Ryabinin This patch initializes KASan shadow region's page table and memory. There are two stage for KASan initializing: 1. At early boot stage the whole shadow region is mapped to just one physical page (kasan_zero_page). It's finished by the function

[PATCH v3 2/6] Disable instrumentation for some code

From: Andrey Ryabinin Disable instrumentation for arch/arm/boot/compressed/* ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those code won't linkd with kernel image. Disable kasan check in the function unwind_pop_register because it doesn't matter that kasan checks

[PATCH v3 1/6] Add TTBR operator for kasan_init

The purpose of this patch is to provide set_ttbr0/get_ttbr0 to kasan_init function. The definitions of cp15 registers should be in arch/arm/include/asm/cp15.h rather than arch/arm/include/asm/kvm_hyp.h, so move them. Cc: Andrey Ryabinin Reviewed-by: Marc Zyngier

[PATCH v3 6/6] Enable KASan for arm

From: Andrey Ryabinin This patch enable kernel address sanitizer for arm. Cc: Andrey Ryabinin Acked-by: Dmitry Vyukov Tested-by: Joel Stanley Tested-by: Florian Fainelli Tested-by:

[PATCH v3 0/6] KASan for arm

From: Andrey Ryabinin Changelog: v3 - v2 - Remove this patch: 2 1-byte checks more safer for memory_is_poisoned_16 because a unaligned load/store of 16 bytes is rare on arm, and this patch is very likely to affect the performance of modern CPUs. ---Acked by: Russell

[PATCH v3 4/6] Define the virtual space of KASan's shadow region

Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for arm kernel address sanitizer. ++ 0x || || || ++ CONFIG_PAGE_OFFSET || || |-> module virtual address space area. ||/ ++ MODULE_VADDR =

[PATCH V5] thermal: Add cooling device's statistics in sysfs

This extends the sysfs interface for thermal cooling devices and exposes some pretty useful statistics. These statistics have proven to be quite useful specially while doing benchmarks related to the task scheduler, where we want to make sure that nothing has disrupted the test, specially the

Re: [PATCH 1/2] perf: riscv: preliminary RISC-V support

Hi Alex, On Mon, Apr 02, 2018 at 03:36:12PM +0800, Alan Kao wrote: > On Sat, Mar 31, 2018 at 03:47:10PM -0700, Alex Solomatnikov wrote: > > The original guess was that maybe, an counter value on a hart is picked > as the minusend, and an old counter value on another hart was recorded > as the

Re: [PATCH 1/2] perf: riscv: preliminary RISC-V support

On Sat, Mar 31, 2018 at 03:47:10PM -0700, Alex Solomatnikov wrote: The original guess was that maybe, an counter value on a hart is picked as the minusend, and an old counter value on another hart was recorded as the subtrahend but numerically larger. Then, the overflow causes by that

Re: [PATCH] Documentation/thermal: Check links and convert to https

On 28-03-18, 22:59, Sanjeev Gupta wrote: > All links working. And why is it important to convert them to https ? > Signed-off-by: Sanjeev Gupta > --- > Documentation/thermal/cpu-cooling-api.txt | 2 +- > Documentation/thermal/nouveau_thermal | 2 +- > 2 files changed, 2