operand cache synonyms and paradoxes for shared mappings:
- Writable mappings are cache-inhibited if the underlying physical
page is mapped at two or more *different* VAs.
This means that read-only mappings at different VAs are still
cacheable. While this could lead to operand cache synonyms, it
won't cause data loss. At worst, we'd have the same read-only
data in several cache-lines.
- If a new cache-inhibited mapping is added for a page which has
existing cacheable mappings, all the existing mappings must be
made cache-inhibited.
- Conversely, if a new cacheable mapping is added for a page which
has existing cache-inhibited mappings, the new mapping must also
be made cache-ibhibited.
- When a mapping is removed, see if we can upgrade any of the
underlying physical page's remaining mappings to cacheable.
TODO: Deal with operand cache aliases (if necessary).
do not let the save game file "string length" exceed the amount of space
supplied. as noted by <stanojr@iserver.sk> on bugtraq.
- minor KNF.
tested by simonb.
and utilize it. This greatly reduces the number of calls to open(2) and
malloc(3) for programs like mozilla that depend on many shared objects
while it doesn't affect performance of small programs.
- krb4/5 support for privsep (krb5 diff was already applied)
includes fake implementaation of getpeereid() from openssh-portable, which
does nothing useful - need improvement.
caveats, but works quite well in a lot of MP cases, and all
UP cases that I have tested. Parts of this will hopefully be
reworked in the not-too-distant future.
