From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,T_DKIMWL_WL_HIGH,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8D85ECDFB8 for ; Mon, 23 Jul 2018 11:13:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7228C20875 for ; Mon, 23 Jul 2018 11:13:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="0GQRoM/Y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7228C20875 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388039AbeGWMNk (ORCPT ); Mon, 23 Jul 2018 08:13:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:37686 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387823AbeGWMNk (ORCPT ); Mon, 23 Jul 2018 08:13:40 -0400 Received: from linux-8ccs (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AC0BD20846; Mon, 23 Jul 2018 11:12:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1532344378; bh=53Bms48kLbc+Q2hZq9XbxepqTQh/eklUn7b6ooiplh4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0GQRoM/Y7IQ7fhjc0Qsqud8ntt+Qju/XWKEhjbzXvyK08S7nIf1igRhneFlUERCup tax0/FIUAlLR8EQkElEUhNNK43pH2OGbZKdYxCplO/PIDUdx+YAMTSIrvNTTQ7whyX xjKTwhS2nmhFNPh+5TBnxCzz4NWUjomQhifTGyPo= Date: Mon, 23 Jul 2018 13:12:51 +0200 From: Jessica Yu To: Martijn Coenen Cc: LKML , Masahiro Yamada , Michal Marek , Geert Uytterhoeven , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Alan Stern , Greg Kroah-Hartman , Oliver Neukum , Arnd Bergmann , Stephen Boyd , Philippe Ombredanne , Kate Stewart , Sam Ravnborg , linux-kbuild@vger.kernel.org, linux-m68k , USB list , USB Storage list , linux-scsi@vger.kernel.org, Linux-Arch , Martijn Coenen , Sandeep Patil , Iliyan Malchev , Joel Fernandes Subject: Re: [PATCH 2/6] module: add support for symbol namespaces. Message-ID: <20180723111251.x2cam6bcuglr4hhz@linux-8ccs> References: <20180716122125.175792-1-maco@android.com> <20180716122125.175792-3-maco@android.com> <20180719163208.5xvrafugpcbhh7kj@linux-8ccs> <20180720144916.fyqpmrtgt23sax6n@linux-8ccs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-OS: Linux linux-8ccs 4.12.14-lp150.11-default x86_64 User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ Martijn Coenen [20/07/18 17:42 +0200]: >On Fri, Jul 20, 2018 at 4:49 PM, Jessica Yu wrote: >> Thanks. Also, it looks like we're currently just warning (in both >> modpost and on module load) if a module uses symbols from a namespace >> it doesn't import. Are you also planning to eventually introduce >> namespace enforcement? > >This is something I've definitely been thinking about, and was curious >what others would think. My main concern with enforcement is that it >will start failing to load out-of-tree modules that use newly >namespaced symbols. On the other hand, I think those modules will need >to be rebuilt anyway to be able to load, because the changes to struct >kernel_symbol make them incompatible with the current kernel. That >could be another reason for having these symbols in a special section >(with its own struct namespaced_kernel_symbol); but on the other hand, >it would make the module loader more complex just to facilitate >out-of-tree drivers, and I'm not sure where the trade-off between >those two falls. IMO I don't think we should bend over backwards to accommodate out-of-tree modules - modifying the module loader to recognize even more special sections to accommodate these OOT modules would be where we'd draw the line I think. >> It'd be trivial to fail the module build in >> modpost as well as reject the module on load if it uses an exported >> symbol belonging to a namespace it doesn't import. Although, I'd go >> with the warnings for a development cycle or two, to gently introduce >> the change in API and let other subsystems as well as out-of-tree >> module developers catch up. > >An approach like that makes sense to me. Another alternative would be >to make it a CONFIG_ option, and let distros/etc. decide what they are >comfortable with. I think going forward I would prefer to have export namespaces to be a normal and regular part of kernel API (as in, we shouldn't require a new option for it), and that the warnings for 1-2 cycles are courteous enough - but anyone with stronger opinions about this should speak up. Thanks, Jessica From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [2/6] module: add support for symbol namespaces. From: Jessica Yu Message-Id: <20180723111251.x2cam6bcuglr4hhz@linux-8ccs> Date: Mon, 23 Jul 2018 13:12:51 +0200 To: Martijn Coenen Cc: LKML , Masahiro Yamada , Michal Marek , Geert Uytterhoeven , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Alan Stern , Greg Kroah-Hartman , Oliver Neukum , Arnd Bergmann , Stephen Boyd , Philippe Ombredanne , Kate Stewart , Sam Ravnborg , linux-kbuild@vger.kernel.org, linux-m68k , USB list , USB Storage list , linux-scsi@vger.kernel.org, Linux-Arch , Martijn Coenen , Sandeep Patil , Iliyan Malchev , Joel Fernandes List-ID: KysrIE1hcnRpam4gQ29lbmVuIFsyMC8wNy8xOCAxNzo0MiArMDIwMF06Cj5PbiBGcmksIEp1bCAy MCwgMjAxOCBhdCA0OjQ5IFBNLCBKZXNzaWNhIFl1IDxqZXl1QGtlcm5lbC5vcmc+IHdyb3RlOgo+ PiBUaGFua3MuIEFsc28sIGl0IGxvb2tzIGxpa2Ugd2UncmUgY3VycmVudGx5IGp1c3Qgd2Fybmlu ZyAoaW4gYm90aAo+PiBtb2Rwb3N0IGFuZCBvbiBtb2R1bGUgbG9hZCkgaWYgYSBtb2R1bGUgdXNl cyBzeW1ib2xzIGZyb20gYSBuYW1lc3BhY2UKPj4gaXQgZG9lc24ndCBpbXBvcnQuIEFyZSB5b3Ug YWxzbyBwbGFubmluZyB0byBldmVudHVhbGx5IGludHJvZHVjZQo+PiBuYW1lc3BhY2UgZW5mb3Jj ZW1lbnQ/Cj4KPlRoaXMgaXMgc29tZXRoaW5nIEkndmUgZGVmaW5pdGVseSBiZWVuIHRoaW5raW5n IGFib3V0LCBhbmQgd2FzIGN1cmlvdXMKPndoYXQgb3RoZXJzIHdvdWxkIHRoaW5rLiBNeSBtYWlu IGNvbmNlcm4gd2l0aCBlbmZvcmNlbWVudCBpcyB0aGF0IGl0Cj53aWxsIHN0YXJ0IGZhaWxpbmcg dG8gbG9hZCBvdXQtb2YtdHJlZSBtb2R1bGVzIHRoYXQgdXNlIG5ld2x5Cj5uYW1lc3BhY2VkIHN5 bWJvbHMuIE9uIHRoZSBvdGhlciBoYW5kLCBJIHRoaW5rIHRob3NlIG1vZHVsZXMgd2lsbCBuZWVk Cj50byBiZSByZWJ1aWx0IGFueXdheSB0byBiZSBhYmxlIHRvIGxvYWQsIGJlY2F1c2UgdGhlIGNo YW5nZXMgdG8gc3RydWN0Cj5rZXJuZWxfc3ltYm9sIG1ha2UgdGhlbSBpbmNvbXBhdGlibGUgd2l0 aCB0aGUgY3VycmVudCBrZXJuZWwuIFRoYXQKPmNvdWxkIGJlIGFub3RoZXIgcmVhc29uIGZvciBo YXZpbmcgdGhlc2Ugc3ltYm9scyBpbiBhIHNwZWNpYWwgc2VjdGlvbgo+KHdpdGggaXRzIG93biBz dHJ1Y3QgbmFtZXNwYWNlZF9rZXJuZWxfc3ltYm9sKTsgYnV0IG9uIHRoZSBvdGhlciBoYW5kLAo+ aXQgd291bGQgbWFrZSB0aGUgbW9kdWxlIGxvYWRlciBtb3JlIGNvbXBsZXgganVzdCB0byBmYWNp bGl0YXRlCj5vdXQtb2YtdHJlZSBkcml2ZXJzLCBhbmQgSSdtIG5vdCBzdXJlIHdoZXJlIHRoZSB0 cmFkZS1vZmYgYmV0d2Vlbgo+dGhvc2UgdHdvIGZhbGxzLgoKSU1PIEkgZG9uJ3QgdGhpbmsgd2Ug c2hvdWxkIGJlbmQgb3ZlciBiYWNrd2FyZHMgdG8gYWNjb21tb2RhdGUKb3V0LW9mLXRyZWUgbW9k dWxlcyAtIG1vZGlmeWluZyB0aGUgbW9kdWxlIGxvYWRlciB0byByZWNvZ25pemUgZXZlbgptb3Jl IHNwZWNpYWwgc2VjdGlvbnMgdG8gYWNjb21tb2RhdGUgdGhlc2UgT09UIG1vZHVsZXMgd291bGQg YmUgd2hlcmUKd2UnZCBkcmF3IHRoZSBsaW5lIEkgdGhpbmsuCgo+PiBJdCdkIGJlIHRyaXZpYWwg dG8gZmFpbCB0aGUgbW9kdWxlIGJ1aWxkIGluCj4+IG1vZHBvc3QgYXMgd2VsbCBhcyByZWplY3Qg dGhlIG1vZHVsZSBvbiBsb2FkIGlmIGl0IHVzZXMgYW4gZXhwb3J0ZWQKPj4gc3ltYm9sIGJlbG9u Z2luZyB0byBhIG5hbWVzcGFjZSBpdCBkb2Vzbid0IGltcG9ydC4gQWx0aG91Z2gsIEknZCBnbwo+ PiB3aXRoIHRoZSB3YXJuaW5ncyBmb3IgYSBkZXZlbG9wbWVudCBjeWNsZSBvciB0d28sIHRvIGdl bnRseSBpbnRyb2R1Y2UKPj4gdGhlIGNoYW5nZSBpbiBBUEkgYW5kIGxldCBvdGhlciBzdWJzeXN0 ZW1zIGFzIHdlbGwgYXMgb3V0LW9mLXRyZWUKPj4gbW9kdWxlIGRldmVsb3BlcnMgY2F0Y2ggdXAu Cj4KPkFuIGFwcHJvYWNoIGxpa2UgdGhhdCBtYWtlcyBzZW5zZSB0byBtZS4gQW5vdGhlciBhbHRl cm5hdGl2ZSB3b3VsZCBiZQo+dG8gbWFrZSBpdCBhIENPTkZJR18gb3B0aW9uLCBhbmQgbGV0IGRp c3Ryb3MvZXRjLiBkZWNpZGUgd2hhdCB0aGV5IGFyZQo+Y29tZm9ydGFibGUgd2l0aC4KCkkgdGhp bmsgZ29pbmcgZm9yd2FyZCBJIHdvdWxkIHByZWZlciB0byBoYXZlIGV4cG9ydCBuYW1lc3BhY2Vz IHRvIGJlIGEKbm9ybWFsIGFuZCByZWd1bGFyIHBhcnQgb2Yga2VybmVsIEFQSSAoYXMgaW4sIHdl IHNob3VsZG4ndCByZXF1aXJlIGEKbmV3IG9wdGlvbiBmb3IgaXQpLCBhbmQgdGhhdCB0aGUgd2Fy bmluZ3MgZm9yIDEtMiBjeWNsZXMgYXJlIGNvdXJ0ZW91cwplbm91Z2ggLSBidXQgYW55b25lIHdp dGggc3Ryb25nZXIgb3BpbmlvbnMgYWJvdXQgdGhpcyBzaG91bGQgc3BlYWsgdXAuCgpUaGFua3Ms CgpKZXNzaWNhCi0tLQpUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGlu ZSAidW5zdWJzY3JpYmUgbGludXgtdXNiIiBpbgp0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFq b3Jkb21vQHZnZXIua2VybmVsLm9yZwpNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdl ci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jessica Yu Subject: Re: [PATCH 2/6] module: add support for symbol namespaces. Date: Mon, 23 Jul 2018 13:12:51 +0200 Message-ID: <20180723111251.x2cam6bcuglr4hhz@linux-8ccs> References: <20180716122125.175792-1-maco@android.com> <20180716122125.175792-3-maco@android.com> <20180719163208.5xvrafugpcbhh7kj@linux-8ccs> <20180720144916.fyqpmrtgt23sax6n@linux-8ccs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Martijn Coenen Cc: LKML , Masahiro Yamada , Michal Marek , Geert Uytterhoeven , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Alan Stern , Greg Kroah-Hartman , Oliver Neukum , Arnd Bergmann , Stephen Boyd , Philippe Ombredanne , Kate Stewart , Sam Ravnborg , linux-kbuild@vger.kernel.org, linux-m68k , USB list USB List-Id: linux-arch.vger.kernel.org +++ Martijn Coenen [20/07/18 17:42 +0200]: >On Fri, Jul 20, 2018 at 4:49 PM, Jessica Yu wrote: >> Thanks. Also, it looks like we're currently just warning (in both >> modpost and on module load) if a module uses symbols from a namespace >> it doesn't import. Are you also planning to eventually introduce >> namespace enforcement? > >This is something I've definitely been thinking about, and was curious >what others would think. My main concern with enforcement is that it >will start failing to load out-of-tree modules that use newly >namespaced symbols. On the other hand, I think those modules will need >to be rebuilt anyway to be able to load, because the changes to struct >kernel_symbol make them incompatible with the current kernel. That >could be another reason for having these symbols in a special section >(with its own struct namespaced_kernel_symbol); but on the other hand, >it would make the module loader more complex just to facilitate >out-of-tree drivers, and I'm not sure where the trade-off between >those two falls. IMO I don't think we should bend over backwards to accommodate out-of-tree modules - modifying the module loader to recognize even more special sections to accommodate these OOT modules would be where we'd draw the line I think. >> It'd be trivial to fail the module build in >> modpost as well as reject the module on load if it uses an exported >> symbol belonging to a namespace it doesn't import. Although, I'd go >> with the warnings for a development cycle or two, to gently introduce >> the change in API and let other subsystems as well as out-of-tree >> module developers catch up. > >An approach like that makes sense to me. Another alternative would be >to make it a CONFIG_ option, and let distros/etc. decide what they are >comfortable with. I think going forward I would prefer to have export namespaces to be a normal and regular part of kernel API (as in, we shouldn't require a new option for it), and that the warnings for 1-2 cycles are courteous enough - but anyone with stronger opinions about this should speak up. Thanks, Jessica