Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751556AbaBHTp4 (ORCPT ); Sat, 8 Feb 2014 14:45:56 -0500 Received: from mail-ve0-f170.google.com ([209.85.128.170]:45934 "EHLO mail-ve0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750862AbaBHTpy (ORCPT ); Sat, 8 Feb 2014 14:45:54 -0500 MIME-Version: 1.0 In-Reply-To: <1391886730-19667-2-git-send-email-ryao@gentoo.org> References: <1391886730-19667-1-git-send-email-ryao@gentoo.org> <1391886730-19667-2-git-send-email-ryao@gentoo.org> Date: Sat, 8 Feb 2014 11:45:53 -0800 X-Google-Sender-Auth: O3oLSnABIGx9ZpHy2MyO2Wxt3n4 Message-ID: Subject: Re: [PATCH 1/2] mm/vmalloc: export is_vmalloc_or_module_addr From: Linus Torvalds To: Richard Yao , Mel Gorman , Andrew Morton , Rik van Riel Cc: Eric Van Hensbergen , Ron Minnich , Latchesar Ionkov , "David S. Miller" , V9FS Develooper Mailing List , Linux Netdev Mailing List , Linux Kernel Mailing List , "Aneesh Kumar K.V" , Will Deacon , Christopher Covington , Matthew Thode Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 8, 2014 at 11:12 AM, Richard Yao 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/