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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Date: Mon, 23 Jul 2018 13:12:51 +0200 From: Jessica Yu 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: Sender: linux-arch-owner@vger.kernel.org List-ID: 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 Message-ID: <20180723111251.lMVrusMhWOVnT2B2v4va86o-hXaQhizcPfyt9gZkF4E@z> +++ 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