All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@linux.intel.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Lukasz Anaczkowski <lukasz.anaczkowski@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	ak@linux.intel.com, kirill.shutemov@linux.intel.com,
	mhocko@suse.com, Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	harish.srinivasappa@intel.com, lukasz.odzioba@intel.com,
	Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH] Linux VM workaround for Knights Landing A/D leak
Date: Tue, 14 Jun 2016 14:37:49 -0700	[thread overview]
Message-ID: <5760792D.90000@linux.intel.com> (raw)
In-Reply-To: <2471A3E8-FF69-4720-A3BF-BDC6094A6A70@gmail.com>

On 06/14/2016 01:16 PM, Nadav Amit wrote:
> Dave Hansen <dave.hansen@linux.intel.com> wrote:
> 
>> On 06/14/2016 09:47 AM, Nadav Amit wrote:
>>> Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> wrote:
>>>
>>>>> From: Andi Kleen <ak@linux.intel.com>
>>>>> +void fix_pte_leak(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
>>>>> +{
>>> Here there should be a call to smp_mb__after_atomic() to synchronize with
>>> switch_mm. I submitted a similar patch, which is still pending (hint).
>>>
>>>>> +	if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids) {
>>>>> +		trace_tlb_flush(TLB_LOCAL_SHOOTDOWN, TLB_FLUSH_ALL);
>>>>> +		flush_tlb_others(mm_cpumask(mm), mm, addr,
>>>>> +				 addr + PAGE_SIZE);
>>>>> +		mb();
>>>>> +		set_pte(ptep, __pte(0));
>>>>> +	}
>>>>> +}
>>
>> Shouldn't that barrier be incorporated in the TLB flush code itself and
>> not every single caller (like this code is)?
>>
>> It is insane to require individual TLB flushers to be concerned with the
>> barriers.
> 
> IMHO it is best to use existing flushing interfaces instead of creating
> new ones. 

Yeah, or make these things a _little_ harder to get wrong.  That little
snippet above isn't so crazy that we should be depending on open-coded
barriers to get it right.

Should we just add a barrier to mm_cpumask() itself?  That should stop
the race.  Or maybe we need a new primitive like:

/*
 * Call this if a full barrier has been executed since the last
 * pagetable modification operation.
 */
static int __other_cpus_need_tlb_flush(struct mm_struct *mm)
{
	/* cpumask_any_but() returns >= nr_cpu_ids if no cpus set. */
	return cpumask_any_but(mm_cpumask(mm), smp_processor_id()) <
		nr_cpu_ids;
}


static int other_cpus_need_tlb_flush(struct mm_struct *mm)
{
	/*
	 * Synchronizes with switch_mm.  Makes sure that we do not
	 * observe a bit having been cleared in mm_cpumask() before
 	 * the other processor has seen our pagetable update.  See
	 * switch_mm().
	 */
	smp_mb__after_atomic();

	return __other_cpus_need_tlb_flush(mm)
}

We should be able to deploy other_cpus_need_tlb_flush() in most of the
cases where we are doing "cpumask_any_but(mm_cpumask(mm),
smp_processor_id()) < nr_cpu_ids".

Right?

> In theory, fix_pte_leak could have used flush_tlb_page. But the problem
> is that flush_tlb_page requires the vm_area_struct as an argument, which
> ptep_get_and_clear (and others) do not have.

That, and we do not want/need to flush the _current_ processor's TLB.
flush_tlb_page() would have done that unnecessarily.  That's not the end
of the world here, but it is a downside.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@linux.intel.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Lukasz Anaczkowski <lukasz.anaczkowski@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	ak@linux.intel.com, kirill.shutemov@linux.intel.com,
	mhocko@suse.com, Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	harish.srinivasappa@intel.com, lukasz.odzioba@intel.com,
	Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH] Linux VM workaround for Knights Landing A/D leak
Date: Tue, 14 Jun 2016 14:37:49 -0700	[thread overview]
Message-ID: <5760792D.90000@linux.intel.com> (raw)
In-Reply-To: <2471A3E8-FF69-4720-A3BF-BDC6094A6A70@gmail.com>

On 06/14/2016 01:16 PM, Nadav Amit wrote:
> Dave Hansen <dave.hansen@linux.intel.com> wrote:
> 
>> On 06/14/2016 09:47 AM, Nadav Amit wrote:
>>> Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> wrote:
>>>
>>>>> From: Andi Kleen <ak@linux.intel.com>
>>>>> +void fix_pte_leak(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
>>>>> +{
>>> Here there should be a call to smp_mb__after_atomic() to synchronize with
>>> switch_mm. I submitted a similar patch, which is still pending (hint).
>>>
>>>>> +	if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids) {
>>>>> +		trace_tlb_flush(TLB_LOCAL_SHOOTDOWN, TLB_FLUSH_ALL);
>>>>> +		flush_tlb_others(mm_cpumask(mm), mm, addr,
>>>>> +				 addr + PAGE_SIZE);
>>>>> +		mb();
>>>>> +		set_pte(ptep, __pte(0));
>>>>> +	}
>>>>> +}
>>
>> Shouldn't that barrier be incorporated in the TLB flush code itself and
>> not every single caller (like this code is)?
>>
>> It is insane to require individual TLB flushers to be concerned with the
>> barriers.
> 
> IMHO it is best to use existing flushing interfaces instead of creating
> new ones. 

Yeah, or make these things a _little_ harder to get wrong.  That little
snippet above isn't so crazy that we should be depending on open-coded
barriers to get it right.

Should we just add a barrier to mm_cpumask() itself?  That should stop
the race.  Or maybe we need a new primitive like:

/*
 * Call this if a full barrier has been executed since the last
 * pagetable modification operation.
 */
static int __other_cpus_need_tlb_flush(struct mm_struct *mm)
{
	/* cpumask_any_but() returns >= nr_cpu_ids if no cpus set. */
	return cpumask_any_but(mm_cpumask(mm), smp_processor_id()) <
		nr_cpu_ids;
}


static int other_cpus_need_tlb_flush(struct mm_struct *mm)
{
	/*
	 * Synchronizes with switch_mm.  Makes sure that we do not
	 * observe a bit having been cleared in mm_cpumask() before
 	 * the other processor has seen our pagetable update.  See
	 * switch_mm().
	 */
	smp_mb__after_atomic();

	return __other_cpus_need_tlb_flush(mm)
}

We should be able to deploy other_cpus_need_tlb_flush() in most of the
cases where we are doing "cpumask_any_but(mm_cpumask(mm),
smp_processor_id()) < nr_cpu_ids".

Right?

> In theory, fix_pte_leak could have used flush_tlb_page. But the problem
> is that flush_tlb_page requires the vm_area_struct as an argument, which
> ptep_get_and_clear (and others) do not have.

That, and we do not want/need to flush the _current_ processor's TLB.
flush_tlb_page() would have done that unnecessarily.  That's not the end
of the world here, but it is a downside.

  reply	other threads:[~2016-06-14 21:37 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14 15:58 [PATCH] Linux VM workaround for Knights Landing A/D leak Lukasz Anaczkowski
2016-06-14 15:58 ` Lukasz Anaczkowski
2016-06-14 16:31 ` kbuild test robot
2016-06-14 16:31   ` kbuild test robot
2016-06-14 16:47 ` Nadav Amit
2016-06-14 16:47   ` Nadav Amit
2016-06-14 16:54   ` Anaczkowski, Lukasz
2016-06-14 16:54     ` Anaczkowski, Lukasz
2016-06-14 17:01   ` [PATCH v2] " Lukasz Anaczkowski
2016-06-14 17:01     ` Lukasz Anaczkowski
2016-06-14 17:24     ` Dave Hansen
2016-06-14 17:24       ` Dave Hansen
2016-06-14 18:34       ` One Thousand Gnomes
2016-06-14 18:34         ` One Thousand Gnomes
2016-06-14 18:54         ` Dave Hansen
2016-06-14 18:54           ` Dave Hansen
2016-06-14 19:19           ` Borislav Petkov
2016-06-14 19:19             ` Borislav Petkov
2016-06-14 20:20             ` H. Peter Anvin
2016-06-14 20:47               ` Borislav Petkov
2016-06-14 20:54                 ` H. Peter Anvin
2016-06-14 21:02                   ` Borislav Petkov
2016-06-14 21:08                     ` H. Peter Anvin
2016-06-14 21:13                     ` H. Peter Anvin
2016-06-14 18:10     ` Borislav Petkov
2016-06-14 18:10       ` Borislav Petkov
2016-06-15 13:12       ` Anaczkowski, Lukasz
2016-06-15 13:12         ` Anaczkowski, Lukasz
2016-06-14 18:38     ` Nadav Amit
2016-06-14 18:38       ` Nadav Amit
2016-06-15 13:12       ` Anaczkowski, Lukasz
2016-06-15 13:12         ` Anaczkowski, Lukasz
2016-06-15 20:04         ` Nadav Amit
2016-06-15 20:04           ` Nadav Amit
2016-06-15 20:10           ` Dave Hansen
2016-06-15 20:10             ` Dave Hansen
2016-06-15 20:26             ` Nadav Amit
2016-06-15 20:26               ` Nadav Amit
2016-06-16 15:14     ` [PATCH v3] " Lukasz Anaczkowski
2016-06-16 15:14       ` Lukasz Anaczkowski
2016-06-16 16:43       ` Nadav Amit
2016-06-16 16:43         ` Nadav Amit
2016-06-16 20:23       ` Dave Hansen
2016-06-16 20:23         ` Dave Hansen
2016-06-14 17:18   ` [PATCH] " Dave Hansen
2016-06-14 17:18     ` Dave Hansen
2016-06-14 20:16     ` Nadav Amit
2016-06-14 20:16       ` Nadav Amit
2016-06-14 21:37       ` Dave Hansen [this message]
2016-06-14 21:37         ` Dave Hansen
2016-06-15  2:20         ` Andy Lutomirski
2016-06-15  2:20           ` Andy Lutomirski
2016-06-15  2:35           ` Nadav Amit
2016-06-15  2:35             ` Nadav Amit
2016-06-15  2:36             ` Andy Lutomirski
2016-06-15  2:36               ` Andy Lutomirski
2016-06-15  2:44               ` Nadav Amit
2016-06-15  2:44                 ` Nadav Amit
2016-06-15  3:09                 ` Andy Lutomirski
2016-06-15  3:09                   ` Andy Lutomirski
2016-06-15  3:20         ` Nadav Amit
2016-06-15  3:20           ` Nadav Amit
2016-06-14 16:58 ` kbuild test robot
2016-06-14 16:58   ` kbuild test robot
2016-06-14 17:19 ` Dave Hansen
2016-06-14 17:19   ` Dave Hansen
2016-06-15 13:06   ` Anaczkowski, Lukasz
2016-06-15 13:06     ` Anaczkowski, Lukasz
2016-06-14 17:47 ` kbuild test robot
2016-06-14 17:47   ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5760792D.90000@linux.intel.com \
    --to=dave.hansen@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=harish.srinivasappa@intel.com \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lukasz.anaczkowski@intel.com \
    --cc=lukasz.odzioba@intel.com \
    --cc=luto@amacapital.net \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.