linux-kernel - Re: [PATCH] mm: fix page_mkclean

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Dec 2006 16:52:21 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	torvalds@...l.org
Cc:	schwidefsky@...ibm.com, a.p.zijlstra@...llo.nl, tbm@...ius.com,
	hugh@...itas.com, nickpiggin@...oo.com.au, arjan@...radead.org,
	andrei.popa@...eo.ro, akpm@...l.org, linux-kernel@...r.kernel.org,
	fw@...eb.enyo.de, mh+linux-kernel@...schlus.de,
	heiko.carstens@...ibm.com, arnd.bergmann@...ibm.com,
	gordonfarquharson@...il.com
Subject: Re: [PATCH] mm: fix page_mkclean_one

From: Linus Torvalds <torvalds@...l.org>
Date: Wed, 27 Dec 2006 16:42:40 -0800 (PST)

> That's fine. In that situation, you shouldn't need any atomic ops at all, 
> I think all our sw page-table operations are already done under the pte 
> lock. 

This is true, but there is one subtlety to this I want to
point out in passing.

That lock can possibly only protect a page of PTEs.

When NR_CPUS >= CONFIG_SPLIT_PTLOCK_CPUS, the locking is done per page
of PTEs, not for all of the page tables of an address space at once.

What this means is that it's really difficult to forcefully block out
all page table operations for a given mm, and I actually needed to do
something like this on sparc64 (when growing the TLB lookup hash
table, you can't let any PTEs change state while the table is
changing).  For my case, I added a spinlock to mm->context since
actually what I need is to block modifications to the hash table
itself during PTE changes.
-
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/