Subject: Re: Minor precedence issues in pmap_remap_pages()?
To: None <port-xen@NetBSD.org>
From: Jed Davis <email@example.com>
Date: 11/15/2005 20:33:32
Jed Davis <firstname.lastname@example.org> writes:
> I noticed a few more of those:
> diff -u -r184.108.40.206 pmap.c
> --- sys/arch/xen/i386/pmap.c 6 Jun 2005 12:16:10 -0000 220.127.116.11
> +++ 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)))))