linux-kernel - trailing flush_tlb_fix_spurious_fault in handle_pte_fault (was Re: [PATCH 1/3] x86/mm: only do a local TLB flush in ptep_set_access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <50D43270.8010506@synopsys.com>
Date:	Fri, 21 Dec 2012 15:27:04 +0530
From:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:	Rik van Riel <riel@...hat.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Michel Lespinasse <walken@...gle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Andrea Arcangeli" <aarcange@...hat.com>,
	Mel Gorman <mgorman@...e.de>,
	"Johannes Weiner" <hannes@...xchg.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	Gilad Ben Yossef <giladb@...hip.com>,
	Andrea Arcangeli <aarcange@...hat.com>
Subject: trailing flush_tlb_fix_spurious_fault in handle_pte_fault (was Re:
 [PATCH 1/3] x86/mm: only do a local TLB flush in ptep_set_access_flags())

On Monday 29 October 2012 08:53 PM, Rik van Riel wrote:
> On 10/26/2012 03:18 PM, Linus Torvalds wrote:
>> On Fri, Oct 26, 2012 at 12:16 PM, Rik van Riel <riel@...hat.com> wrote:
>>>
>>> I can change the text of the changelog, however it looks
>>> like do_wp_page does actually use ptep_set_access_flags
>>> to set the write bit in the pte...
>>>
>>> I guess both need to be reflected in the changelog text
>>> somehow?
>>
>> Yeah, and by now, after all this discussion, I suspect it should be
>> committed with a comment too. Commit messages are good and all, but
>> unless chasing a particular bug they introduced, we shouldn't expect
>> people to read them for background information.
> 
> Now that we have the TLB things taken care of, and
> comments to patches 10/31 and 26/31 have been addressed,
> is there anything else that needs to be done before
> these NUMA patches can be merged?
> 
> Anyone, this is a good time to speak up. We have some
> time to address whatever concern you may have.
> 

Hi,

I know I'm very late in speaking up - but still I'll hazard a try. This is not
exactly the same topic but closely related.

There is a a different call to flush_tlb_fix_spurious( ), towards the end of
handle_pte_fault( ) which commit 61c77326d "x86, mm: Avoid unnecessary TLB flush"
made no-op for X86. However is this really needed for any arch at all - even if we
don't know all the arch specific quirks.

Given the code flow below

handle_pte_fault( )
....
....
if ptep_set_access_flags()-> if PTE chg remote TLB shot (pgtable-generic.c ver)
   update_mmu_cache       -> if PTE chg local TLB possibly shot too
else
   flush_tlb_fix_spurious_fault -> PTE didn't change - still remote TLB shotdown

So for PTE unchanged case, we default to doing remote TLB IPIs (barring X86) -
unless arch makes this macro NULL.

Thing is, in case of SMP races - due to PTE being different - any fixups to
local/remote will be handled within ptep_set_access_flags( ) - arch-specific or
generic versions. What I fail to understand is need to do anything - specially a
remote shootdown, for PTE not changed case.

I could shut up and just make it NO-OP for ARC, but ....

Please note that for the record, the addition of this special case was done via
following change. It might help answer what I feel to comprehend.

2005-10-29 1a44e14 [PATCH] .text page fault SMP scalability optimization

I might be totally off track so please feel free to bash me - but atleast I would
end up knowing more !

Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/