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:	Sat, 8 Feb 2014 11:45:53 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Richard Yao <ryao@...too.org>, Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>
Cc:	Eric Van Hensbergen <ericvh@...il.com>,
	Ron Minnich <rminnich@...dia.gov>,
	Latchesar Ionkov <lucho@...kov.net>,
	"David S. Miller" <davem@...emloft.net>,
	V9FS Develooper Mailing List 
	<v9fs-developer@...ts.sourceforge.net>,
	Linux Netdev Mailing List <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Will Deacon <will.deacon@....com>,
	Christopher Covington <cov@...eaurora.org>,
	Matthew Thode <mthode@...ode.org>
Subject: Re: [PATCH 1/2] mm/vmalloc: export is_vmalloc_or_module_addr

On Sat, Feb 8, 2014 at 11:12 AM, Richard Yao <ryao@...too.org> wrote:
> 9p-virtio needs is_vmalloc_or_module_addr exported before a patch can be
> merged to prevent the virtio zero-copy routines from triggering a
> hypervisor page fault when loading kernel modules:
>
> https://groups.google.com/forum/#!topic/linux.kernel/eRR7AyLE29Y
>
> Without this export, the kernel build breaks with that patch applied and
> CONFIG_NET_9P_VIRTIO=m. With this export in place, all is well.

I absolutely *detest* this patch.

Not so much because is_vmalloc_or_module_addr() should never be used,
but because the particular use in question is pure and utter garbage.

There are valid reasons to use "is_vmalloc_or_module_addr()", but
those are along the lines of drivers/char/mem.c, which says "return
-ENXIO for this crap".

And btw, that horrid crap called "kmap_to_page()" needs to die too.
When is it *ever* valid to use a kmap'ed page for IO? Here's a clue:
never.

I notice that we have a similar abortion in "get_kernel_page[s]()",
which probably has the same broken source.

We need to get *rid* of this crap, rather than add more of it. I
should have looked more closely, but it came in through Andrew, which
generally makes me go "ok, Andrew sends me a VM patch - apply". In
this case it was clearly a huge mistake.

So who the f*ck sends static module data as IO? Just stop doing that.
What's And that idiotic kmap_to_page() really needs to die too.

Those *disgusting* get_kernel_page[s]() functions came with a
commentary about "The initial user is expected to be NFS.." and that
is still the *only* user. The fact that *everybody* else has been able
to avoid that crap should tell us something.

Mel, Rik, this needs to die. I'm sorry I didn't notice how crap it was earlier.

And what's the backtrace that gets mentioned - but not quoted - for
the horrible 9p crap? So that we can see who the guilty party is that
thinks that it's somehow ok to pass module addresses off to other
kernel users..

Please let's just fix the real problem, don't add more horridness on
top of it because somebody messed up earlier.

                  Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ