linux-kernel - Re: [patch] x86: optimize __pa() to be linear again on 64-bit x86

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, 27 Feb 2009 16:11:51 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Nick Piggin <nickpiggin@...oo.com.au>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	rusty@...tcorp.com.au, tglx@...utronix.de, x86@...nel.org,
	linux-kernel@...r.kernel.org, hpa@...or.com, jeremy@...p.org,
	cpw@....com
Subject: Re: [patch] x86: optimize __pa() to be linear again on 64-bit x86

Hello, Ingo.

Ingo Molnar wrote:
> * Tejun Heo <tj@...nel.org> wrote:
> 
>> Hello,
>>
>> Ingo Molnar wrote:
>>> Yeah, we can do this complete conversion.
>>>
>>> I'll clean it up some more. I think the best representation of 
>>> this will be via a virt_to_sym() and sym_to_virt() space. That 
>>> makes it really clear when we are moving from the symbol space 
>>> to the linear space and back.
>> For arch code, maybe it's maintainable but with my driver developer
>> hat on I gotta say virt_to_page() not working on .data/.bss is quite
>> scary. [...]
> 
> Well, we have a debug mechanism in place.
> 
> As i suggested it in my first mail we can run with debug enabled 
> for a cycle and then turn on the optimization by default (with 
> the debug option still available too).

I don't know.  The failure mode just seems to subtle to me and we'll
be able to gain most of the benefits by using the fast version at
appropriate places without adding any risk.

> Drivers doing DMA on .data/.bss items is rather questionable 
> anyway (and dangerous as well, on any platform where there's 
> coherency problems if DMA is misaligned, etc.), and a quick look 
> shows there's at most 2-3 dozen examples of that in all of 
> drivers/*.

Gained benefit vs. added danger equation just doesn't seem right to
me.  Yes, we'll be able to filter most of them in a cycle or two but
we will never know whether it's fully safe or not.  Please note that
when it goes wrong, it can go wrong silently corrupting some unrelated
stuff.  When there is a way to achieve almost the same level of
performance gain in safe way, I don't think doing it this way is a
good choice.  Also, if we do this, we're basically introducing new API
by changing semantics of an existing one in a way that can break the
current users, which we really should avoid.

Thanks.

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