linux-kernel - Re: [PATCH 4/9] Vmi fix highpte

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:	Fri, 02 Mar 2007 23:43:54 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Zachary Amsden <zach@...are.com>
CC:	Chris Wright <chrisw@...s-sol.org>, Andi Kleen <ak@....de>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>,
	Virtualization Mailing List <virtualization@...ts.osdl.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/9] Vmi fix highpte

Zachary Amsden wrote:
> Yes, but the hook point now happens before the page table mapping.

Did you change that since you posted the patch?  Sounds like a larger
change than the one I'm proposing.

>   Not that it should cause a problem.  But we've been testing things
> the original way for over a year now, and if we want to get the fix
> upstream for 2.6.21, it seems better to upstream a more tested fix
> rather than a new way of doing things, even if it is identical in theory.

Sure.

> That said, I have no problems with the approach you propose going
> forward.  I just don't think it is appropriate for an -rc release,
> because it provides no tangible benefit for any of the in-kernel code,
> and causes a lot of retesting.  I still believe there is almost zero
> risk to doing things the way you propose.  But I am also a firm
> believer in shipping what is tested and working unless there is a
> compelling reason to do otherwise.  And if Xen is not going to be in
> 2.6.21, the compelling reason becomes getting the code working for
> both of us for 2.6.22 - so let's do that, and keep the patches from
> Andrew's -mm tree around to make sure that we have a suitable patch
> base that can be applied to 2.6.21 for any distros that are willing to
> pick up the Xen paravirt-ops.
>
> Sound reasonable?

I can deal with the change going into -git, but it does seem awkward
knowing that it is the wrong change and it will be replaced by something
else almost immediately.

My main concern is that the Xen patch queue is complex enough as-is, and
I've been trying hard to remove dependencies on other uncommitted
patches.   It's doubly complex because I'm not really sure if I'm
targeting Andrew or Andi's tree as a base, though at the moment -git
seems to work either way.

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