[PATCH 0/3] fix several TLB batch races

Nadav and Mel founded several subtle races caused by TLB batching. This patchset aims for solving thoses problems using embedding [set|clear]_tlb_flush_pending to TLB batching API. With that, places to know TLB flush pending catch it up by using mm_tlb_flush_pending. Each patch includes detailed

[PATCH 0/3] fix several TLB batch races

Nadav and Mel founded several subtle races caused by TLB batching. This patchset aims for solving thoses problems using embedding [set|clear]_tlb_flush_pending to TLB batching API. With that, places to know TLB flush pending catch it up by using mm_tlb_flush_pending. Each patch includes detailed

[PATCH 3/3] mm: fix KSM data corruption

Nadav reported KSM can corrupt the user data by the TLB batching race[1]. That means data user written can be lost. Quote from Nadav Amit " For this race we need 4 CPUs: CPU0: Caches a writable and dirty PTE entry, and uses the stale value for write later. CPU1: Runs madvise_free on the range

[PATCH 3/3] mm: fix KSM data corruption

Nadav reported KSM can corrupt the user data by the TLB batching race[1]. That means data user written can be lost. Quote from Nadav Amit " For this race we need 4 CPUs: CPU0: Caches a writable and dirty PTE entry, and uses the stale value for write later. CPU1: Runs madvise_free on the range

[PATCH 2/3] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem

Nadav reported parallel MADV_DONTNEED on same range has a stale TLB problem and Mel fixed it[1] and found same problem on MADV_FREE[2]. Quote from Mel Gorman "The race in question is CPU 0 running madv_free and updating some PTEs while CPU 1 is also running madv_free and looking at the same

[PATCH 2/3] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem

Nadav reported parallel MADV_DONTNEED on same range has a stale TLB problem and Mel fixed it[1] and found same problem on MADV_FREE[2]. Quote from Mel Gorman "The race in question is CPU 0 running madv_free and updating some PTEs while CPU 1 is also running madv_free and looking at the same

[PATCH 1/3] mm: make tlb_flush_pending global

Currently, tlb_flush_pending is used only for CONFIG_[NUMA_BALANCING| COMPACTION] but upcoming patches to solve subtle TLB flush bacting problem will use it regardless of compaction/numa so this patch doesn't remove the dependency. Cc: Nadav Amit Cc: Mel Gorman

[PATCH 1/3] mm: make tlb_flush_pending global

Currently, tlb_flush_pending is used only for CONFIG_[NUMA_BALANCING| COMPACTION] but upcoming patches to solve subtle TLB flush bacting problem will use it regardless of compaction/numa so this patch doesn't remove the dependency. Cc: Nadav Amit Cc: Mel Gorman Signed-off-by: Minchan Kim ---

[PATCH] ARM: rockchip: enable ZONE_DMA for non 64-bit capable peripherals

Most IP cores on ARM Rockchip platforms can only address 32 bits of physical memory for DMA. Thus ZONE_DMA should be enabled when LPAE is activated. Signed-off-by: Tao Huang --- arch/arm/mach-rockchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] ARM: rockchip: enable ZONE_DMA for non 64-bit capable peripherals

Most IP cores on ARM Rockchip platforms can only address 32 bits of physical memory for DMA. Thus ZONE_DMA should be enabled when LPAE is activated. Signed-off-by: Tao Huang --- arch/arm/mach-rockchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/Kconfig

Re: [RFC PATCH 0/8] EDAC, mce_amd: Add a tracepoint for the decoded error

* Borislav Petkov wrote: > BUT(!), I just realized, I *think* I can address this much more elegantly: > extend trace_mce_record() by adding the decoded string as its last argument. > And > that's fine, I'm being told, because adding arguments to the tracepoints is > not > a

Re: [RFC PATCH 0/8] EDAC, mce_amd: Add a tracepoint for the decoded error

* Borislav Petkov wrote: > BUT(!), I just realized, I *think* I can address this much more elegantly: > extend trace_mce_record() by adding the decoded string as its last argument. > And > that's fine, I'm being told, because adding arguments to the tracepoints is > not > a big deal,

Re: [PATCH -tip v5 1/2] irq: Introduce CONFIG_IRQENTRY kconfig

* Masami Hiramatsu wrote: > Introduce CONFIG_IRQENTRY to simplify generating > irqentry and softirqentry text sections. > Currently generating those sections depends on > CONFIG_FUNCTION_GRAPH_TRACER and/or CONFIG_KASAN, in > each source code. This moves those #ifdef

Re: [PATCH -tip v5 1/2] irq: Introduce CONFIG_IRQENTRY kconfig

* Masami Hiramatsu wrote: > Introduce CONFIG_IRQENTRY to simplify generating > irqentry and softirqentry text sections. > Currently generating those sections depends on > CONFIG_FUNCTION_GRAPH_TRACER and/or CONFIG_KASAN, in > each source code. This moves those #ifdef dependencies > into

[PATCH 2/2] init/main.c: Fixes quoted string split across lines & missing blank line after declaration

Signed-off-by: Janani S --- init/main.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/init/main.c b/init/main.c index f8eb4966..920b829 100644 --- a/init/main.c +++ b/init/main.c @@ -176,6 +176,7 @@ static bool __init obsolete_checksetup(char *line)

[PATCH 2/2] init/main.c: Fixes quoted string split across lines & missing blank line after declaration

Signed-off-by: Janani S --- init/main.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/init/main.c b/init/main.c index f8eb4966..920b829 100644 --- a/init/main.c +++ b/init/main.c @@ -176,6 +176,7 @@ static bool __init obsolete_checksetup(char *line) p =

Re: [RFC PATCH 3/3] mm: shm: Use new hugetlb size encoding definitions

On Thu 27-07-17 14:18:11, Mike Kravetz wrote: > On 07/27/2017 12:50 AM, Michal Hocko wrote: > > On Wed 26-07-17 10:39:30, Mike Kravetz wrote: > >> On 07/26/2017 03:07 AM, Michal Hocko wrote: > >>> On Wed 26-07-17 11:53:38, Michal Hocko wrote: > On Mon 17-07-17 15:28:01, Mike Kravetz wrote: >

Re: [RFC PATCH 3/3] mm: shm: Use new hugetlb size encoding definitions

On Thu 27-07-17 14:18:11, Mike Kravetz wrote: > On 07/27/2017 12:50 AM, Michal Hocko wrote: > > On Wed 26-07-17 10:39:30, Mike Kravetz wrote: > >> On 07/26/2017 03:07 AM, Michal Hocko wrote: > >>> On Wed 26-07-17 11:53:38, Michal Hocko wrote: > On Mon 17-07-17 15:28:01, Mike Kravetz wrote: >

Re: [PATCH 2/4] KVM: VMX: avoid double list add with VT-d posted interrupts

On 28/07/2017 04:31, Longpeng (Mike) wrote: > Hi Paolo, > > On 2017/6/6 18:57, Paolo Bonzini wrote: > >> In some cases, for example involving hot-unplug of assigned >> devices, pi_post_block can forget to remove the vCPU from the >> blocked_vcpu_list. When this happens, the next call to >>

Re: [PATCH v1 2/2] acpi, x86: Remove encryption mask from ACPI page protection type

* Tom Lendacky wrote: > > > + * in memory in an encrypted state so return a protection attribute > > > + * that does not have the encryption bit set. > > >*/ > > > - return PAGE_KERNEL; > > > + return sme_active() ? PAGE_KERNEL_IO : PAGE_KERNEL; > > > >

Re: [PATCH 2/4] KVM: VMX: avoid double list add with VT-d posted interrupts

On 28/07/2017 04:31, Longpeng (Mike) wrote: > Hi Paolo, > > On 2017/6/6 18:57, Paolo Bonzini wrote: > >> In some cases, for example involving hot-unplug of assigned >> devices, pi_post_block can forget to remove the vCPU from the >> blocked_vcpu_list. When this happens, the next call to >>

Re: [PATCH v1 2/2] acpi, x86: Remove encryption mask from ACPI page protection type

* Tom Lendacky wrote: > > > + * in memory in an encrypted state so return a protection attribute > > > + * that does not have the encryption bit set. > > >*/ > > > - return PAGE_KERNEL; > > > + return sme_active() ? PAGE_KERNEL_IO : PAGE_KERNEL; > > > > Why isn't there a

Re: [PATCH] mm, oom: allow oom reaper to race with exit_mmap

On Thu 27-07-17 16:55:59, Andrea Arcangeli wrote: > On Thu, Jul 27, 2017 at 08:50:24AM +0200, Michal Hocko wrote: > > Yes this will work and it won't depend on the oom_lock. But isn't it > > just more ugly than simply doing > > > > if (tsk_is_oom_victim) { > >

Re: [PATCH] mm, oom: allow oom reaper to race with exit_mmap

On Thu 27-07-17 16:55:59, Andrea Arcangeli wrote: > On Thu, Jul 27, 2017 at 08:50:24AM +0200, Michal Hocko wrote: > > Yes this will work and it won't depend on the oom_lock. But isn't it > > just more ugly than simply doing > > > > if (tsk_is_oom_victim) { > >

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

Jens Axboe writes: > On 07/27/2017 08:47 AM, Bart Van Assche wrote: >> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote: >>> The bug looks like SCSI running the queue inline from IRQ >>> context, that's not a good idea. ... >> >> scsi_run_queue() works fine if no scheduler is

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

Jens Axboe writes: > On 07/27/2017 08:47 AM, Bart Van Assche wrote: >> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote: >>> The bug looks like SCSI running the queue inline from IRQ >>> context, that's not a good idea. ... >> >> scsi_run_queue() works fine if no scheduler is configured.

Re: [PATCH v2] qe: fix compile issue for arm64

Zhao Qiang writes: > Signed-off-by: Zhao Qiang > --- > Changes for v2: > - include all Errata QE_General4 in #ifdef > > drivers/soc/fsl/qe/qe.c | 2 ++ > 1 file changed, 2 insertions(+) AFAICS this driver can only be built on PPC, what am I

Re: [PATCH v2] qe: fix compile issue for arm64

Zhao Qiang writes: > Signed-off-by: Zhao Qiang > --- > Changes for v2: > - include all Errata QE_General4 in #ifdef > > drivers/soc/fsl/qe/qe.c | 2 ++ > 1 file changed, 2 insertions(+) AFAICS this driver can only be built on PPC, what am I missing? config QUICC_ENGINE bool

[PATCH] init:main.c: Fixed issues in Block comments and removed braces in single statement if block

Signed-off-by: Janani S --- init/main.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/init/main.c b/init/main.c index 052481f..f8eb4966 100644 --- a/init/main.c +++ b/init/main.c @@ -181,7 +181,8 @@ static bool __init obsolete_checksetup(char

[PATCH] init:main.c: Fixed issues in Block comments and removed braces in single statement if block

Signed-off-by: Janani S --- init/main.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/init/main.c b/init/main.c index 052481f..f8eb4966 100644 --- a/init/main.c +++ b/init/main.c @@ -181,7 +181,8 @@ static bool __init obsolete_checksetup(char *line)

[PATCH v6.1 4/7] drm/rockchip: vop: group vop registers

Grouping the vop registers facilitates make register definition clearer, and also is useful for different vop reuse the same group register. Signed-off-by: Mark Yao Reviewed-by: Jeffy Chen --- Changes in v6.1 - fix Null pointer crash on

[PATCH v6.1 4/7] drm/rockchip: vop: group vop registers

Grouping the vop registers facilitates make register definition clearer, and also is useful for different vop reuse the same group register. Signed-off-by: Mark Yao Reviewed-by: Jeffy Chen --- Changes in v6.1 - fix Null pointer crash on vop_reg_set drivers/gpu/drm/rockchip/rockchip_drm_vop.c

RE: [PATCH] cpufreq: x86: Make scaling_cur_freq behave more as expected

On 2017.07.27 17:13 Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > After commit f8475cef9008 "x86: use common aperfmperf_khz_on_cpu() to > calculate KHz using APERF/MPERF" the scaling_cur_freq policy attribute > in sysfs only behaves as expected on x86 with

RE: [PATCH] cpufreq: x86: Make scaling_cur_freq behave more as expected

On 2017.07.27 17:13 Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > After commit f8475cef9008 "x86: use common aperfmperf_khz_on_cpu() to > calculate KHz using APERF/MPERF" the scaling_cur_freq policy attribute > in sysfs only behaves as expected on x86 with APERF/MPERF registers >

Re: [PATCH 2/2] arm64: dts: Add device node for pmi8994 gpios

On Fri, Jul 28, 2017 at 2:30 AM, Stephen Boyd wrote: > On 07/26/2017 11:30 PM, Vivek Gautam wrote: >> Signed-off-by: Vivek Gautam >> --- >> arch/arm64/boot/dts/qcom/pmi8994.dtsi | 17 + >> 1 file changed, 17 insertions(+) >> >>

Re: [PATCH 2/2] arm64: dts: Add device node for pmi8994 gpios

On Fri, Jul 28, 2017 at 2:30 AM, Stephen Boyd wrote: > On 07/26/2017 11:30 PM, Vivek Gautam wrote: >> Signed-off-by: Vivek Gautam >> --- >> arch/arm64/boot/dts/qcom/pmi8994.dtsi | 17 + >> 1 file changed, 17 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/qcom/pmi8994.dtsi

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 27-07-17, 12:55, Saravana Kannan wrote: > Yes. Simplifying isn't always about number of lines of code. It's also about > abstraction. Having generic scheduler code care about HW details doesn't > seem nice. I can argue that even the policy->cpus field is also hardware specific, isn't it ? And

Re: [PATCH] device property: Fix usecount for of_graph_get_port_parent()

* Rob Herring [170727 15:19]: > On Thu, Jul 27, 2017 at 4:44 AM, Tony Lindgren wrote: > > --- a/drivers/of/property.c > > +++ b/drivers/of/property.c > > @@ -708,6 +708,15 @@ struct device_node *of_graph_get_port_parent(struct > > device_node *node) > > {

Re: [PATCH] device property: Fix usecount for of_graph_get_port_parent()

* Rob Herring [170727 15:19]: > On Thu, Jul 27, 2017 at 4:44 AM, Tony Lindgren wrote: > > --- a/drivers/of/property.c > > +++ b/drivers/of/property.c > > @@ -708,6 +708,15 @@ struct device_node *of_graph_get_port_parent(struct > > device_node *node) > > { > > unsigned int depth; > > >

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 27-07-17, 12:55, Saravana Kannan wrote: > Yes. Simplifying isn't always about number of lines of code. It's also about > abstraction. Having generic scheduler code care about HW details doesn't > seem nice. I can argue that even the policy->cpus field is also hardware specific, isn't it ? And

<    11   12   13   14   15   16