Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753568AbaBJTnq (ORCPT ); Mon, 10 Feb 2014 14:43:46 -0500 Received: from mail-vc0-f171.google.com ([209.85.220.171]:53224 "EHLO mail-vc0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753528AbaBJTnl (ORCPT ); Mon, 10 Feb 2014 14:43:41 -0500 MIME-Version: 1.0 In-Reply-To: <52F929A6.8040209@mit.edu> References: <1391886730-19667-1-git-send-email-ryao@gentoo.org> <1391886730-19667-2-git-send-email-ryao@gentoo.org> <52F68C67.6050606@gentoo.org> <52F6972C.2030307@gentoo.org> <52F929A6.8040209@mit.edu> Date: Mon, 10 Feb 2014 11:43:39 -0800 X-Google-Sender-Auth: VxLSjf61E7YvSiT4VhQeOgxVRuk Message-ID: Subject: Re: [PATCH 1/2] mm/vmalloc: export is_vmalloc_or_module_addr From: Linus Torvalds To: Andy Lutomirski Cc: Richard Yao , Mel Gorman , Andrew Morton , Rik van Riel , 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 Mon, Feb 10, 2014 at 11:33 AM, Andy Lutomirski wrote: > > I agree that reading to module space is awful, but is it obviously > terrible for a module to do this: > > static const char header[] = {...}; > kernel_write(file, header, sizeof(header), 0); Yes, it is terrible. Don't do it. It shouldn't work. Now, whether it is "obvious" or not is immaterial. It might be hard to notice, but let's face it, we are kernel programmers. Our interfaces aren't designed for convenience, they are for working well and efficiently. And if that happens to mean that you shouldn't do IO on kmap'ed pages, or use random static data in your modules, that is what it means. We have lots of other rules too. People should deal with it, and realize that in the kernel we absolutely *have* to try to minimize the problem space as much as possible. The usual computer sciencey approach of "make things as generic as possible so that you can reuse the code" stuff is generally bullshit even in other contexts (example: STL), but it's _particularly_ bad for the kernel. It's much better to have strict rules about what is acceptable. 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/