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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Feb 2009 14:57:52 +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 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.  We can try to convert whatever which could be affected but

* They aren't clear at all not only when the code is being written but
  also when someone tries to use the code which can be buried several
  layers under.

* The failure cases can be hidden very well so that they can pass most
  tests unnoticed.  For example, buffer reserved for exception cases
  allocated statically which is usually used by PIO (no problem) but
  on a few selected controllers DMA is used.

* The failure mode is unobvious and very nasty.  With the debug code
  left out, the failure simply is mistranslated address or page
  pointer.  We might end up feeding the wrong address to controllers.
  The addresses are likely to be invalid but we really have no idea
  how the controllers would react.  If it ever happens, it's gonna be
  nasty.

* There isn't any point in trying to save a few cycles when we're deep
  in the IO path.  The cost simply is negligible compared to all the
  stuff necessary for programing devices.

So, I really think we should do what Nick suggested.  Make a fast
version and use it where the saved few cycles actually matter.  A
postfix which is more descriptive than _fast would be better tho.

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/