All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	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
Date: Fri, 29 Apr 2022 09:07:57 +0100	[thread overview]
Message-ID: <20220429090757.1acb943a@sal.lan> (raw)
In-Reply-To: <YmuZovuDaCYDDG4c@phenom.ffwll.local>

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.


> 
> Adding Greg for device model questions like this.
> -Daniel
> 
> > ---
> > 
> > See [PATCH 0/2] at: https://lore.kernel.org/all/cover.1651212016.git.mchehab@kernel.org/
> > 
> >  include/linux/module.h |  7 +++++++
> >  kernel/module/main.c   | 31 +++++++++++++++++++++++++++++++
> >  2 files changed, 38 insertions(+)
> > 
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index 46d4d5f2516e..be74f807e41d 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -596,6 +596,8 @@ static inline bool within_module(unsigned long addr, const struct module *mod)
> >  /* Search for module by name: must be in a RCU-sched critical section. */
> >  struct module *find_module(const char *name);
> >  
> > +int module_add_named_dependency(const char *name, struct module *this);
> > +
> >  /* Returns 0 and fills in value, defined and namebuf, or -ERANGE if
> >     symnum out of range. */
> >  int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
> > @@ -772,6 +774,11 @@ static inline int lookup_module_symbol_attrs(unsigned long addr, unsigned long *
> >  	return -ERANGE;
> >  }
> >  
> > +static inline int module_add_named_dependency(const char *name, struct module *this)
> > +{
> > +	return 0;
> > +}
> > +
> >  static inline int module_get_kallsym(unsigned int symnum, unsigned long *value,
> >  					char *type, char *name,
> >  					char *module_name, int *exported)
> > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > index 05a42d8fcd7a..dbd577ccc38c 100644
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -631,6 +631,37 @@ static int ref_module(struct module *a, struct module *b)
> >  	return 0;
> >  }
> >  
> > +int module_add_named_dependency(const char *name, struct module *this)
> > +{
> > +	struct module *mod;
> > +	int ret;
> > +
> > +	if (!name || !this || !this->name) {
> > +		return -EINVAL;
> > +	}
> > +
> > +	mutex_lock(&module_mutex);
> > +	mod = find_module(name);
> > +	if (!mod) {
> > +		ret = -EINVAL;
> > +		goto ret;
> > +	}
> > +
> > +	ret = ref_module(this, mod);
> > +	if (ret)
> > +		goto ret;
> > +
> > +#ifdef CONFIG_MODULE_UNLOAD
> > +	ret = sysfs_create_link(mod->holders_dir,
> > +				&this->mkobj.kobj, this->name);
> > +#endif
> > +
> > +ret:
> > +	mutex_unlock(&module_mutex);
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(module_add_named_dependency);
> > +
> >  /* Clear the unload stuff of the module. */
> >  static void module_unload_free(struct module *mod)
> >  {
> > -- 
> > 2.35.1
> >   
> 

WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Kai Vehmanen <kai.vehmanen@intel.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	intel-gfx@lists.freedesktop.org,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	David Airlie <airlied@linux.ie>,
	Luis Chamberlain <mcgrof@kernel.org>,
	mauro.chehab@intel.com, Dan Williams <dan.j.williams@intel.com>,
	linux-modules@vger.kernel.org,
	Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
Subject: Re: [PATCH 1/2] module: add a function to add module references
Date: Fri, 29 Apr 2022 09:07:57 +0100	[thread overview]
Message-ID: <20220429090757.1acb943a@sal.lan> (raw)
In-Reply-To: <YmuZovuDaCYDDG4c@phenom.ffwll.local>

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.


> 
> Adding Greg for device model questions like this.
> -Daniel
> 
> > ---
> > 
> > See [PATCH 0/2] at: https://lore.kernel.org/all/cover.1651212016.git.mchehab@kernel.org/
> > 
> >  include/linux/module.h |  7 +++++++
> >  kernel/module/main.c   | 31 +++++++++++++++++++++++++++++++
> >  2 files changed, 38 insertions(+)
> > 
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index 46d4d5f2516e..be74f807e41d 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -596,6 +596,8 @@ static inline bool within_module(unsigned long addr, const struct module *mod)
> >  /* Search for module by name: must be in a RCU-sched critical section. */
> >  struct module *find_module(const char *name);
> >  
> > +int module_add_named_dependency(const char *name, struct module *this);
> > +
> >  /* Returns 0 and fills in value, defined and namebuf, or -ERANGE if
> >     symnum out of range. */
> >  int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
> > @@ -772,6 +774,11 @@ static inline int lookup_module_symbol_attrs(unsigned long addr, unsigned long *
> >  	return -ERANGE;
> >  }
> >  
> > +static inline int module_add_named_dependency(const char *name, struct module *this)
> > +{
> > +	return 0;
> > +}
> > +
> >  static inline int module_get_kallsym(unsigned int symnum, unsigned long *value,
> >  					char *type, char *name,
> >  					char *module_name, int *exported)
> > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > index 05a42d8fcd7a..dbd577ccc38c 100644
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -631,6 +631,37 @@ static int ref_module(struct module *a, struct module *b)
> >  	return 0;
> >  }
> >  
> > +int module_add_named_dependency(const char *name, struct module *this)
> > +{
> > +	struct module *mod;
> > +	int ret;
> > +
> > +	if (!name || !this || !this->name) {
> > +		return -EINVAL;
> > +	}
> > +
> > +	mutex_lock(&module_mutex);
> > +	mod = find_module(name);
> > +	if (!mod) {
> > +		ret = -EINVAL;
> > +		goto ret;
> > +	}
> > +
> > +	ret = ref_module(this, mod);
> > +	if (ret)
> > +		goto ret;
> > +
> > +#ifdef CONFIG_MODULE_UNLOAD
> > +	ret = sysfs_create_link(mod->holders_dir,
> > +				&this->mkobj.kobj, this->name);
> > +#endif
> > +
> > +ret:
> > +	mutex_unlock(&module_mutex);
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(module_add_named_dependency);
> > +
> >  /* Clear the unload stuff of the module. */
> >  static void module_unload_free(struct module *mod)
> >  {
> > -- 
> > 2.35.1
> >   
> 

WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Kai Vehmanen <kai.vehmanen@intel.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	intel-gfx@lists.freedesktop.org,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	David Airlie <airlied@linux.ie>,
	Luis Chamberlain <mcgrof@kernel.org>,
	mauro.chehab@intel.com, Dan Williams <dan.j.williams@intel.com>,
	linux-modules@vger.kernel.org,
	Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
Date: Fri, 29 Apr 2022 09:07:57 +0100	[thread overview]
Message-ID: <20220429090757.1acb943a@sal.lan> (raw)
In-Reply-To: <YmuZovuDaCYDDG4c@phenom.ffwll.local>

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.


> 
> Adding Greg for device model questions like this.
> -Daniel
> 
> > ---
> > 
> > See [PATCH 0/2] at: https://lore.kernel.org/all/cover.1651212016.git.mchehab@kernel.org/
> > 
> >  include/linux/module.h |  7 +++++++
> >  kernel/module/main.c   | 31 +++++++++++++++++++++++++++++++
> >  2 files changed, 38 insertions(+)
> > 
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index 46d4d5f2516e..be74f807e41d 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -596,6 +596,8 @@ static inline bool within_module(unsigned long addr, const struct module *mod)
> >  /* Search for module by name: must be in a RCU-sched critical section. */
> >  struct module *find_module(const char *name);
> >  
> > +int module_add_named_dependency(const char *name, struct module *this);
> > +
> >  /* Returns 0 and fills in value, defined and namebuf, or -ERANGE if
> >     symnum out of range. */
> >  int module_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
> > @@ -772,6 +774,11 @@ static inline int lookup_module_symbol_attrs(unsigned long addr, unsigned long *
> >  	return -ERANGE;
> >  }
> >  
> > +static inline int module_add_named_dependency(const char *name, struct module *this)
> > +{
> > +	return 0;
> > +}
> > +
> >  static inline int module_get_kallsym(unsigned int symnum, unsigned long *value,
> >  					char *type, char *name,
> >  					char *module_name, int *exported)
> > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > index 05a42d8fcd7a..dbd577ccc38c 100644
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -631,6 +631,37 @@ static int ref_module(struct module *a, struct module *b)
> >  	return 0;
> >  }
> >  
> > +int module_add_named_dependency(const char *name, struct module *this)
> > +{
> > +	struct module *mod;
> > +	int ret;
> > +
> > +	if (!name || !this || !this->name) {
> > +		return -EINVAL;
> > +	}
> > +
> > +	mutex_lock(&module_mutex);
> > +	mod = find_module(name);
> > +	if (!mod) {
> > +		ret = -EINVAL;
> > +		goto ret;
> > +	}
> > +
> > +	ret = ref_module(this, mod);
> > +	if (ret)
> > +		goto ret;
> > +
> > +#ifdef CONFIG_MODULE_UNLOAD
> > +	ret = sysfs_create_link(mod->holders_dir,
> > +				&this->mkobj.kobj, this->name);
> > +#endif
> > +
> > +ret:
> > +	mutex_unlock(&module_mutex);
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(module_add_named_dependency);
> > +
> >  /* Clear the unload stuff of the module. */
> >  static void module_unload_free(struct module *mod)
> >  {
> > -- 
> > 2.35.1
> >   
> 

  reply	other threads:[~2022-04-29  8:08 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29  6:31 [PATCH 0/2] Let userspace know when snd-hda-intel needs i915 Mauro Carvalho Chehab
2022-04-29  6:31 ` Mauro Carvalho Chehab
2022-04-29  6:31 ` [Intel-gfx] " Mauro Carvalho Chehab
2022-04-29  6:31 ` Mauro Carvalho Chehab
2022-04-29  6:31 ` [PATCH 1/2] module: add a function to add module references Mauro Carvalho Chehab
2022-04-29  6:31   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-04-29  6:31   ` Mauro Carvalho Chehab
2022-04-29  7:54   ` Daniel Vetter
2022-04-29  7:54     ` [Intel-gfx] " Daniel Vetter
2022-04-29  7:54     ` Daniel Vetter
2022-04-29  8:07     ` Mauro Carvalho Chehab [this message]
2022-04-29  8:07       ` [Intel-gfx] " Mauro Carvalho Chehab
2022-04-29  8:07       ` Mauro Carvalho Chehab
2022-04-29  8:30       ` Greg KH
2022-04-29  8:30         ` [Intel-gfx] " Greg KH
2022-04-29  8:30         ` Greg KH
2022-04-29  9:15         ` Mauro Carvalho Chehab
2022-04-29  9:15           ` [Intel-gfx] " Mauro Carvalho Chehab
2022-04-29  9:15           ` Mauro Carvalho Chehab
2022-04-29 10:10           ` Greg KH
2022-04-29 10:10             ` [Intel-gfx] " Greg KH
2022-04-29 10:10             ` Greg KH
2022-04-29 10:23             ` Mauro Carvalho Chehab
2022-04-29 10:23               ` [Intel-gfx] " Mauro Carvalho Chehab
2022-04-29 10:23               ` Mauro Carvalho Chehab
2022-04-29 10:36               ` Greg KH
2022-04-29 10:36                 ` [Intel-gfx] " Greg KH
2022-04-29 10:36                 ` Greg KH
2022-05-04  8:49                 ` Daniel Vetter
2022-05-04  8:49                   ` Daniel Vetter
2022-05-04  8:49                   ` [Intel-gfx] " Daniel Vetter
2022-04-29 15:52               ` Lucas De Marchi
2022-04-29 15:52                 ` Lucas De Marchi
2022-04-29  6:31 ` [PATCH 2/2] ALSA: hda - identify when audio is provided by a video driver Mauro Carvalho Chehab
2022-04-29  6:31   ` Mauro Carvalho Chehab
2022-04-29  6:31   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-04-29  6:31   ` Mauro Carvalho Chehab
2022-04-29  6:56 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Let userspace know when snd-hda-intel needs i915 Patchwork
2022-04-29  6:56 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-29  7:19 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-29  8:40 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220429090757.1acb943a@sal.lan \
    --to=mchehab@kernel.org \
    --cc=airlied@linux.ie \
    --cc=dan.j.williams@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kai.vehmanen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=mauro.chehab@intel.com \
    --cc=mcgrof@kernel.org \
    --cc=pierre-louis.bossart@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.