Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp776035ybe; Thu, 5 Sep 2019 05:55:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqym7dM49T6kXrlgF/nOLoOpxDz9/Y5jk4U/hxhiYlzdH0voLeu27fv2NBFawfhI2vOaDW6v X-Received: by 2002:a63:5765:: with SMTP id h37mr2931542pgm.183.1567688105263; Thu, 05 Sep 2019 05:55:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567688105; cv=none; d=google.com; s=arc-20160816; b=C0keGDZl2kiFdXxa9KqwxGaMzWAgiaHUd2Es4di55gn5zu3EXyu1/uV50+QzSvMqRV 5ZVy6RKjQuAlvm0x3Qp4eOjV8mMvD30akPKEAy2tTy+sSSBN6pGku1Ba1FXf0SfztxKT 8ikabRL0nT8fg9K1vwQGePWTpkX+GoycYEylwZPlGUs00tvQzwrJPNh1QDgVM+PBs4OZ YWpVf5vgm4Z00IK9hhwWMJqmaxa09Le/FFVoWddait93U87OH4PF0fjZu3HyR+tjYkAf VA+InFamcVpXANzbI5mWRI2JPN+JzaPKayqJPCaocckY5aIN/J/H9APH7jrl7ti+fuuT WmBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=sArbTYkYhREngQkqCBDtLITongQycXcOekafmveU9NI=; b=C2emE/wG7oifBILAS7Tf0fuOkE7EOKNn9/5cwZhNDYEKLZb0j2sVjsC/lwckJ34M+t ZGPypmflWWidwjXPZzVB3h7zGyID6b71qFNeqj1y+Cv/DlVdtS9J/wUuBgiQaMmryP9q JEzXsDEFsdAFELeycvF9LQEK7qJ6nrI05rxXMLP2Q7IxR9J2lWa6s5p767vBciafQJwE YqngceC4T7sAvG4wdd/Sx5nv3OuGKdjEAVhzUWEZF+NQFwXlumDTKxLvqTUHADilENiz 6RrwFC5IklwuNHOOls/ISFaBh1rXrfze5fYy2Co1JSXykmdpwn4Z3xlEDKGNDv68tJtJ rv9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=cxyT0NCR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v189si2126859pfv.99.2019.09.05.05.54.49; Thu, 05 Sep 2019 05:55:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=cxyT0NCR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388042AbfIEKlz (ORCPT + 99 others); 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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ 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