linux-kernel - Re: [RFC] page fault retry with NOPAGE

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, 20 Sep 2006 10:05:12 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Mike Waychison <mikew@...gle.com>
Cc:	Andrew Morton <akpm@...l.org>, linux-mm@...ck.org,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>
Subject: Re: [RFC] page fault retry with NOPAGE_RETRY

> I need to re-read your mail and Andrew as at this point, I don't quite
> see why we need that args and/or that current->flags bit instead of
> always returning all the way to userland and let the faulting
> instruction happen again (which means you don't block in the kernel, can
> take signals etc... thus do you actually need to prevent multiple
> retries ?)

Actually... I can see it's faster to not return all the way and take the
fault again ... though only in some cases. For example, if the pte has
been filled in the meantime (concurrent faults) it's actually faster to
just go back. The only reason I see why you need those args is to tell
the no_page() handler wether retrying is acceptable or wether it should
use the old way. Any reason why this is necessary at all ? What are you
trying to avoid by not letting it always do the retry path ?

My thinking was something around the lines of no_page() always does the
retry logic. Then, we do something like:

handle_pte_fault() gets modified. If do_no_page() returns
VM_FAULT_RETRY, it checks pte_present() again. If the PTE is present, it
returns VM_FAULT_MINOR. If PTE is absent, it checks for signals, and
returns VM_FAULT_MINOR if a signal is pending. If PTE is absent and no
signals are pending, it returns VM_FAULT_RETRY.

In addition, we still need to modify all archs do_page_fault() to handle
VM_FAULT_RETRY...

Or is there a specific scenario you are trying to avoid by keeping this
mecanism for preventing retries ?

Ben.

-
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/