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]

Message-ID: <45E7F405.6020507@vmware.com>
Date:	Fri, 02 Mar 2007 01:53:09 -0800
From:	Zachary Amsden <zach@...are.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
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

Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>   
>> Yeah, actually that does work, since you pass the km_type, we can use
>> that.  But I would rather not respin this for 2.6.21; getting this
>> 100% right can be tricky, and we've already done a good deal of
>> testing on this patch the way it is.
>>     
>
> It seems fairly low risk to me; its basically the same structure with
> the same calls happening in the same order, but just slightly rearranged
> in the source.  Of course, if I'd seen this patch earlier I could have
> given you earlier feedback...
>   

I've been sending out this particular patch or a variant of it for a 
long time.  It did get lost for a while during the paravirt-ops 
conversion, however.  You're the first to give any feedback on it.

>>   Do you have any objection to me creating a patch for -mm tree that
>> implements kmap_atomic_pte the way you have described above and
>> attaching it to the Xen patch series, but leaving the current patch as
>> is for now?
>>     
>
> Not particularly, but it seems odd to put something in knowing its going
> to be immediately replaced.  What's the urgency?
>   

Better to keep what is known working for now, even if it is going to be 
replaced later... code is easy to change in development cycles, less 
easy to fix when nearing release.  It really is easy to mess up one of 
the pte conversions by, say, shift the wrong value or calculate wrong or 
PAE dependent PTE offset.  Plus it is harder to test, since you need > 
896 M memory for your VM before the code even gets run.

Not that I expect anything to go wrong with it, but I would prefer to 
err on the side of caution for now, that's all.

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