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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 C4778C3A5A5 for ; Thu, 5 Sep 2019 10:41:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9EFA022CF6 for ; Thu, 5 Sep 2019 10:41:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567680115; bh=f3g6+GkFfq7dsW3Hcfdj3HneqZPXcFMZ8t3cgR3qUcw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=xZM1l4ujCLUBEMQgJSc9fcmybiXSzXVcscuWBbGQVQ2LPu//jK+RE20C8/POz2Iv9 yuBFd1+BmyiHGplN/yImPNE+dg7rxrVki79jwEbpR3kLbmrOtRO7R9natLTOLOUIAJ NIodTiOeYQOECxePCwHSzBJ/Ne3F8l9vR4GtT6Kk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387799AbfIEKlz (ORCPT ); Thu, 5 Sep 2019 06:41:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:39376 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731215AbfIEKlz (ORCPT ); Thu, 5 Sep 2019 06:41:55 -0400 Received: from linux-8ccs (nat.nue.novell.com [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 8503A206BB; Thu, 5 Sep 2019 10:41:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567680113; bh=f3g6+GkFfq7dsW3Hcfdj3HneqZPXcFMZ8t3cgR3qUcw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cxyT0NCRQWEW0CzJzXAKo/7ZeMnS91FwRcZR6V2djERXI2dpN9lo6kUNOwDCKqSN9 +cwK/irArqaUooaX6It16R2kiGAZeIOM5GO2r0wJjuyVPaiYm5PqRdPBDrAgecqkEB o4pc6bNQO33ZjIl7KaHnCnv5U5WRXIE9dnMY9p/Q= Date: Thu, 5 Sep 2019 12:41:47 +0200 From: Jessica Yu To: Matthew Dharm Cc: Guenter Roeck , Masahiro Yamada , Matthias Maennich , Linux Kernel Mailing List , "Cc: Android Kernel" , Arnd Bergmann , Greg Kroah-Hartman , "Joel Fernandes (Google)" , Lucas De Marchi , maco@android.com, sspatil@google.com, Will Deacon , Linux Kbuild mailing list , linux-modules@vger.kernel.org, linux-usb , USB Mass Storage on Linux , linux-watchdog@vger.kernel.org Subject: Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace Message-ID: <20190905104147.GA27788@linux-8ccs> References: <20180716122125.175792-1-maco@android.com> <20190903150638.242049-1-maennich@google.com> <20190903150638.242049-13-maennich@google.com> <20190903161045.GA22754@roeck-us.net> 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.12.61-default x86_64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: owner-linux-modules@vger.kernel.org Precedence: bulk List-ID: +++ Matthew Dharm [04/09/19 09:16 -0700]: >On Wed, Sep 4, 2019 at 5:12 AM Guenter Roeck wrote: >> >> Note that I don't object to the patch set in general. There may be symbols >> which only need be exported in the context of a single subsystem or even >> driver (if a driver consists of more than one module). For example, a mfd >> driver may export symbols which should only be called by its client drivers. >> In such a situation, it may well be beneficial to limit the use of exported >> symbols. > >I can appreciate this benefit. > >> I am not sure what good that does in practice (if I understand correctly, >> a driver only has to declare that it wants to use a restricted use symbol >> if it wants to use it), but that is a different question. > >I think this question implies that you are coming from the perspective >of "security" or wanting to restrict access to the underlying >functions, rather than wanting to clean-up the way symbols are handled >for manageability / maintainability purposes (which is the goal, as I >understand it). > >HOWEVER, I have one question: If these patches are included, and >someone wants to introduce a bit of code which needs to use two >symbols from different namespaces but with the same name, can that be >done? That is, if driver A has symbol 'foo' and driver B has symbol >'foo' (both in their respective namespaces), and driver C wants to use >A.foo and B.foo, can that be supported? As of now, we currently don't support this - modpost will warn if a symbol is exported more than once (across modules + vmlinux), and the module loader currently assumes exported symbol names are unique. Do you have a concrete use case? If there is a strong need for this, I don't think it'd be too hard to implement. Thanks, Jessica