Jed Davis <jdev@panix.com> writes:

> I noticed a few more of those:
>
> diff -u -r1.8.2.3 pmap.c
> --- sys/arch/xen/i386/pmap.c    6 Jun 2005 12:16:10 -0000       1.8.2.3
> +++ sys/arch/xen/i386/pmap.c    21 Jul 2005 03:55:43 -0000
> @@ -3715,7 +3715,7 @@
>                  * wired count might change...
>                  */
>                 pmap->pm_stats.wired_count +=
> -                   ((npte & PG_W) ? 1 : 0 - (opte & PG_W) ? 1 : 0);
> +                   ((npte & PG_W) ? 1 : 0) - ((opte & PG_W) ? 1 : 0);

Anyone object to my committing them, now that I can do that?  It's
pretty obvious that the code is wrong as is, and that my parens are
what was meant.


This will not, however, entirely fix the pm_stats; at the least,
they're not rolled back if the actual MMU update fails.

Furthermore, the wisdom of charging foreign pages against a user
process's locked-memory rlimit (as happens, and I believe it's
related) is questionable, although it did find a bug in libxc (which
I, um, kind of haven't fed upstream yet because it's tied up with some
other stuff whose correctness/sanity I wasn't (and am not) sure of).

Yet furthermore, pmap_remap_pages as it's used from userspace Needs
Help, and the conditions above would go away once that happens, but
that's beyond the scope of this post.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))