Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Fri, 29 Apr 2022 12:36:01 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Mauro Carvalho Chehab <mchehab@kernel.org>
Cc:     Daniel Vetter <daniel@ffwll.ch>,
        Luis Chamberlain <mcgrof@kernel.org>, mauro.chehab@intel.com,
        Kai Vehmanen <kai.vehmanen@intel.com>,
        Lucas De Marchi <lucas.demarchi@intel.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@intel.com>,
        dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
        linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org,
        David Airlie <airlied@linux.ie>,
        Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH 1/2] module: add a function to add module references
Message-ID: <Ymu/keaggU6Uajom@kroah.com>
References: <cover.1651212016.git.mchehab@kernel.org>
 <a078eb2e46d00ec59c8a91ea0afa5190730c9e58.1651212016.git.mchehab@kernel.org>
 <YmuZovuDaCYDDG4c@phenom.ffwll.local>
 <20220429090757.1acb943a@sal.lan>
 <YmuiKcHgl+nABvo/@kroah.com>
 <20220429101503.4048db5b@sal.lan>
 <Ymu5f8EjdC1Mawzt@kroah.com>
 <20220429112351.0e044950@sal.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220429112351.0e044950@sal.lan>
Precedence: bulk

On Fri, Apr 29, 2022 at 11:23:51AM +0100, Mauro Carvalho Chehab wrote:
> Em Fri, 29 Apr 2022 12:10:07 +0200
> Greg KH <gregkh@linuxfoundation.org> escreveu:
> 
> > On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote:
> > > HI Greg,
> > > 
> > > Em Fri, 29 Apr 2022 10:30:33 +0200
> > > Greg KH <gregkh@linuxfoundation.org> escreveu:
> > >   
> > > > On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab wrote:  
> > > > > Hi Daniel,
> > > > > 
> > > > > Em Fri, 29 Apr 2022 09:54:10 +0200
> > > > > Daniel Vetter <daniel@ffwll.ch> escreveu:
> > > > >     
> > > > > > On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab wrote:    
> > > > > > > Sometimes, device drivers are bound using indirect references,
> > > > > > > which is not visible when looking at /proc/modules or lsmod.
> > > > > > > 
> > > > > > > Add a function to allow setting up module references for such
> > > > > > > cases.
> > > > > > > 
> > > > > > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>      
> > > > > > 
> > > > > > This sounds like duct tape at the wrong level. We should have a
> > > > > > device_link connecting these devices, and maybe device_link internally
> > > > > > needs to make sure the respective driver modules stay around for long
> > > > > > enough too. But open-coding this all over the place into every driver that
> > > > > > has some kind of cross-driver dependency sounds terrible.
> > > > > > 
> > > > > > Or maybe the bug is that the snd driver keeps accessing the hw/component
> > > > > > side when that is just plain gone. Iirc there's still fundamental issues
> > > > > > there on the sound side of things, which have been attempted to paper over
> > > > > > by timeouts and stuff like that in the past instead of enforcing a hard
> > > > > > link between the snd and i915 side.    
> > > > > 
> > > > > I agree with you that the device link between snd-hda and the DRM driver
> > > > > should properly handle unbinding on both directions. This is something
> > > > > that require further discussions with ALSA and DRM people, and we should
> > > > > keep working on it.
> > > > > 
> > > > > Yet, the binding between those drivers do exist, but, despite other
> > > > > similar inter-driver bindings being properly reported by lsmod, this one
> > > > > is invisible for userspace.
> > > > > 
> > > > > What this series does is to make such binding visible. As simple as that.    
> > > > 
> > > > It also increases the reference count, and creates a user/kernel api
> > > > with the symlinks, right?  Will the reference count increase prevent the
> > > > modules from now being unloadable?
> > > >
> > > > This feels like a very "weak" link between modules that should not be
> > > > needed if reference counting is implemented properly (so that things are
> > > > cleaned up in the correct order.)  
> > > 
> > > The refcount increment exists even without this patch, as
> > > hda_component_master_bind() at sound/hda/hdac_component.c uses 
> > > try_module_get() when it creates the device link.  
> > 
> > Ok, then why shouldn't try_module_get() be creating this link instead of
> > having to manually do it this way again?  You don't want to have to go
> > around and add this call to all users of that function, right?
> 
> Works for me, but this is not a too trivial change, as the new 
> try_module_get() function will require two parameters, instead of one:
> 
> 	- the module to be referenced;
> 	- the module which will reference it.
> 
> On trivial cases, one will be THIS_MODULE, but, in the specific case
> of snd_hda, the binding is done via an ancillary routine under 
> snd_hda_core, but the actual binding happens at snd_hda_intel.

For calls that want to increment a module reference on behalf of a
different code segment than is calling it, create a new function so we
can audit-the-heck out of those code paths as odds are, they are unsafe.

For the normal code path, just turn try_module_get() into a macro that
includes THIS_MODULE as part of it like we do for the driver register
functions (see usb_register_driver() in include/linux/usb.h as an
example of how to do that.)

> Ok, we could add a __try_module_get() (or whatever other name that
> would properly express what it does) with two parameters, and then
> define try_module_get() as:
> 
> 	#define try_module_get(mod) __try_module_get(mod, THIS_MODULE)

Yes, that's the way forward.

thanks,

greg k-h