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
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
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
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
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
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
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
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
---
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
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
* 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
* 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,
* 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
* 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
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)
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 =
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:
>
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:
>
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
>>
* 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;
> >
> >
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
>>
* 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
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) {
> >
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) {
> >
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
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.
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
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
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
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)
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
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
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
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
>
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(+)
>>
>>
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
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
* 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)
> > {
* 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;
> >
>
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
1501 - 1540 of 1540 matches
Mail list logo