All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	alsa-devel@alsa-project.org, mauro.chehab@linux.intel.com,
	David Airlie <airlied@linux.ie>,
	Greg KH <gregkh@linuxfoundation.org>,
	intel-gfx@lists.freedesktop.org,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	Takashi Iwai <tiwai@suse.com>,
	dri-devel@lists.freedesktop.org, Jaroslav Kysela <perex@perex.cz>,
	Kai Vehmanen <kai.vehmanen@intel.com>,
	linux-modules@vger.kernel.org,
	Dan Williams <dan.j.williams@intel.com>,
	linux-kernel@vger.kernel.org,
	Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
Subject: Re: [Intel-gfx] [PATCH v5 1/2] module: update dependencies at try_module_get()
Date: Mon, 9 May 2022 18:56:20 +0200	[thread overview]
Message-ID: <20220509185620.05567716@coco.lan> (raw)
In-Reply-To: <YnRDIfthGJXdY23h@intel.intel>

Em Thu, 5 May 2022 23:35:29 +0200
Andi Shyti <andi.shyti@linux.intel.com> escreveu:

> Hi Mauro,
> 
> [...]
> 
> > +static int ref_module_dependency(struct module *mod, struct module *this)
> > +{
> > +	int ret;
> > +
> > +	if (!this || !this->name)
> > +		return -EINVAL;
> > +
> > +	if (mod == this)
> > +		return 0;
> > +
> > +	mutex_lock(&module_mutex);
> > +
> > +	ret = ref_module(this, mod);
> > +
> > +#ifdef CONFIG_MODULE_UNLOAD
> > +	if (ret)
> > +		goto ret;
> > +
> > +	ret = sysfs_create_link(mod->holders_dir,
> > +				&this->mkobj.kobj, this->name);
> > +#endif
> > +
> > +ret:
> > +	mutex_unlock(&module_mutex);
> > +	return ret;
> > +}
> > +
> >  /* Clear the unload stuff of the module. */
> >  static void module_unload_free(struct module *mod)
> >  {
> > @@ -841,24 +886,16 @@ void __module_get(struct module *module)
> >  }
> >  EXPORT_SYMBOL(__module_get);
> >  
> > -bool try_module_get(struct module *module)
> > +bool try_module_get_owner(struct module *module, struct module *this)
> >  {
> > -	bool ret = true;
> > +	int ret = __try_module_get(module);
> >  
> > -	if (module) {
> > -		preempt_disable();
> > -		/* Note: here, we can fail to get a reference */
> > -		if (likely(module_is_live(module) &&
> > -			   atomic_inc_not_zero(&module->refcnt) != 0))
> > -			trace_module_get(module, _RET_IP_);
> > -		else
> > -			ret = false;
> > +	if (ret)
> > +		ref_module_dependency(module, this);  
> 
> do we care about the return value here?

I don't think it should care about the return value, as a failure to
create a sysfs node for the holder or to add it to the holders list
is not fatal: modules can still continue working without that.

Also, I opted to be conservative here: currently, not creating these
doesn't cause try_module_get() to fail. I'm not sure what would be the
impact if this starts to fail.

So, right now, I'm opting to just ignore the return value. Perhaps
in the future this could a warning (similarly to what sysfs create
link does).

Regards,
Mauro

> 
> Andi
> 
> >  
> > -		preempt_enable();
> > -	}
> >  	return ret;
> >  }
> > -EXPORT_SYMBOL(try_module_get);
> > +EXPORT_SYMBOL(try_module_get_owner);
> >  
> >  void module_put(struct module *module)
> >  {
> > -- 
> > 2.35.1  



Thanks,
Mauro

WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: mauro.chehab@linux.intel.com, linux-kernel@vger.kernel.org,
	David Airlie <airlied@linux.ie>,
	Greg KH <gregkh@linuxfoundation.org>,
	intel-gfx@lists.freedesktop.org,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org,
	Takashi Iwai <tiwai@suse.com>,
	Kai Vehmanen <kai.vehmanen@intel.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Jaroslav Kysela <perex@perex.cz>,
	linux-modules@vger.kernel.org,
	Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
Subject: Re: [Intel-gfx] [PATCH v5 1/2] module: update dependencies at try_module_get()
Date: Mon, 9 May 2022 18:56:20 +0200	[thread overview]
Message-ID: <20220509185620.05567716@coco.lan> (raw)
In-Reply-To: <YnRDIfthGJXdY23h@intel.intel>

Em Thu, 5 May 2022 23:35:29 +0200
Andi Shyti <andi.shyti@linux.intel.com> escreveu:

> Hi Mauro,
> 
> [...]
> 
> > +static int ref_module_dependency(struct module *mod, struct module *this)
> > +{
> > +	int ret;
> > +
> > +	if (!this || !this->name)
> > +		return -EINVAL;
> > +
> > +	if (mod == this)
> > +		return 0;
> > +
> > +	mutex_lock(&module_mutex);
> > +
> > +	ret = ref_module(this, mod);
> > +
> > +#ifdef CONFIG_MODULE_UNLOAD
> > +	if (ret)
> > +		goto ret;
> > +
> > +	ret = sysfs_create_link(mod->holders_dir,
> > +				&this->mkobj.kobj, this->name);
> > +#endif
> > +
> > +ret:
> > +	mutex_unlock(&module_mutex);
> > +	return ret;
> > +}
> > +
> >  /* Clear the unload stuff of the module. */
> >  static void module_unload_free(struct module *mod)
> >  {
> > @@ -841,24 +886,16 @@ void __module_get(struct module *module)
> >  }
> >  EXPORT_SYMBOL(__module_get);
> >  
> > -bool try_module_get(struct module *module)
> > +bool try_module_get_owner(struct module *module, struct module *this)
> >  {
> > -	bool ret = true;
> > +	int ret = __try_module_get(module);
> >  
> > -	if (module) {
> > -		preempt_disable();
> > -		/* Note: here, we can fail to get a reference */
> > -		if (likely(module_is_live(module) &&
> > -			   atomic_inc_not_zero(&module->refcnt) != 0))
> > -			trace_module_get(module, _RET_IP_);
> > -		else
> > -			ret = false;
> > +	if (ret)
> > +		ref_module_dependency(module, this);  
> 
> do we care about the return value here?

I don't think it should care about the return value, as a failure to
create a sysfs node for the holder or to add it to the holders list
is not fatal: modules can still continue working without that.

Also, I opted to be conservative here: currently, not creating these
doesn't cause try_module_get() to fail. I'm not sure what would be the
impact if this starts to fail.

So, right now, I'm opting to just ignore the return value. Perhaps
in the future this could a warning (similarly to what sysfs create
link does).

Regards,
Mauro

> 
> Andi
> 
> >  
> > -		preempt_enable();
> > -	}
> >  	return ret;
> >  }
> > -EXPORT_SYMBOL(try_module_get);
> > +EXPORT_SYMBOL(try_module_get_owner);
> >  
> >  void module_put(struct module *module)
> >  {
> > -- 
> > 2.35.1  



Thanks,
Mauro

WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: mauro.chehab@linux.intel.com, linux-kernel@vger.kernel.org,
	David Airlie <airlied@linux.ie>,
	Greg KH <gregkh@linuxfoundation.org>,
	intel-gfx@lists.freedesktop.org,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org,
	Takashi Iwai <tiwai@suse.com>,
	Kai Vehmanen <kai.vehmanen@intel.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	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 v5 1/2] module: update dependencies at try_module_get()
Date: Mon, 9 May 2022 18:56:20 +0200	[thread overview]
Message-ID: <20220509185620.05567716@coco.lan> (raw)
In-Reply-To: <YnRDIfthGJXdY23h@intel.intel>

Em Thu, 5 May 2022 23:35:29 +0200
Andi Shyti <andi.shyti@linux.intel.com> escreveu:

> Hi Mauro,
> 
> [...]
> 
> > +static int ref_module_dependency(struct module *mod, struct module *this)
> > +{
> > +	int ret;
> > +
> > +	if (!this || !this->name)
> > +		return -EINVAL;
> > +
> > +	if (mod == this)
> > +		return 0;
> > +
> > +	mutex_lock(&module_mutex);
> > +
> > +	ret = ref_module(this, mod);
> > +
> > +#ifdef CONFIG_MODULE_UNLOAD
> > +	if (ret)
> > +		goto ret;
> > +
> > +	ret = sysfs_create_link(mod->holders_dir,
> > +				&this->mkobj.kobj, this->name);
> > +#endif
> > +
> > +ret:
> > +	mutex_unlock(&module_mutex);
> > +	return ret;
> > +}
> > +
> >  /* Clear the unload stuff of the module. */
> >  static void module_unload_free(struct module *mod)
> >  {
> > @@ -841,24 +886,16 @@ void __module_get(struct module *module)
> >  }
> >  EXPORT_SYMBOL(__module_get);
> >  
> > -bool try_module_get(struct module *module)
> > +bool try_module_get_owner(struct module *module, struct module *this)
> >  {
> > -	bool ret = true;
> > +	int ret = __try_module_get(module);
> >  
> > -	if (module) {
> > -		preempt_disable();
> > -		/* Note: here, we can fail to get a reference */
> > -		if (likely(module_is_live(module) &&
> > -			   atomic_inc_not_zero(&module->refcnt) != 0))
> > -			trace_module_get(module, _RET_IP_);
> > -		else
> > -			ret = false;
> > +	if (ret)
> > +		ref_module_dependency(module, this);  
> 
> do we care about the return value here?

I don't think it should care about the return value, as a failure to
create a sysfs node for the holder or to add it to the holders list
is not fatal: modules can still continue working without that.

Also, I opted to be conservative here: currently, not creating these
doesn't cause try_module_get() to fail. I'm not sure what would be the
impact if this starts to fail.

So, right now, I'm opting to just ignore the return value. Perhaps
in the future this could a warning (similarly to what sysfs create
link does).

Regards,
Mauro

> 
> Andi
> 
> >  
> > -		preempt_enable();
> > -	}
> >  	return ret;
> >  }
> > -EXPORT_SYMBOL(try_module_get);
> > +EXPORT_SYMBOL(try_module_get_owner);
> >  
> >  void module_put(struct module *module)
> >  {
> > -- 
> > 2.35.1  



Thanks,
Mauro

  reply	other threads:[~2022-05-09 16:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-30 20:04 [PATCH v5 0/2] Let userspace know when snd-hda-intel needs i915 Mauro Carvalho Chehab
2022-04-30 20:04 ` Mauro Carvalho Chehab
2022-04-30 20:04 ` [Intel-gfx] " Mauro Carvalho Chehab
2022-04-30 20:04 ` Mauro Carvalho Chehab
2022-04-30 20:04 ` [PATCH v5 1/2] module: update dependencies at try_module_get() Mauro Carvalho Chehab
2022-04-30 20:04   ` Mauro Carvalho Chehab
2022-04-30 20:04   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-04-30 20:04   ` Mauro Carvalho Chehab
2022-05-02  6:08   ` Christophe Leroy
2022-05-02  6:08     ` [Intel-gfx] " Christophe Leroy
2022-05-02  6:08     ` Christophe Leroy
2022-05-02  6:08     ` Christophe Leroy
2022-05-05 21:35   ` [Intel-gfx] " Andi Shyti
2022-05-05 21:35     ` Andi Shyti
2022-05-09 16:56     ` Mauro Carvalho Chehab [this message]
2022-05-09 16:56       ` Mauro Carvalho Chehab
2022-05-09 16:56       ` Mauro Carvalho Chehab
2022-04-30 20:04 ` [PATCH v5 2/2] ALSA: hda - identify when audio is provided by a video driver Mauro Carvalho Chehab
2022-04-30 20:04   ` Mauro Carvalho Chehab
2022-04-30 20:04   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-04-30 20:04   ` Mauro Carvalho Chehab
2022-05-09  8:48   ` Takashi Iwai
2022-05-09  8:48     ` Takashi Iwai
2022-05-09  8:48     ` Takashi Iwai
2022-05-09  8:48     ` [Intel-gfx] " Takashi Iwai
2022-04-30 20:21 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Let userspace know when snd-hda-intel needs i915 Patchwork
2022-04-30 20:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-30 22:42 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=20220509185620.05567716@coco.lan \
    --to=mchehab@kernel.org \
    --cc=airlied@linux.ie \
    --cc=alsa-devel@alsa-project.org \
    --cc=andi.shyti@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --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@linux.intel.com \
    --cc=mcgrof@kernel.org \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@intel.com \
    --cc=tiwai@suse.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.