All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Karsten Wiese <annabellesgarden@yahoo.de>
Cc: mingo@elte.hu, alsa-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Reset file->f_op in	snd_card_file_remove(). Take 2
Date: Thu, 05 Oct 2006 12:43:50 +0200	[thread overview]
Message-ID: <s5hmz8boxeh.wl%tiwai@suse.de> (raw)
In-Reply-To: <200610050141.47847.annabellesgarden@yahoo.de>

At Thu, 5 Oct 2006 01:41:47 +0200,
Karsten Wiese wrote:
> 
> Am Mittwoch, 4. Oktober 2006 22:15 schrieb Takashi Iwai:
> > 
> > This looks like a good optoin.  But one thing we have to be careful
> > about is the module counter since the owner is different between the
> > old f_op and disconnect_f_op...
> > 
> here is rc1, will test later.
> Feel free to pick it apart ;-)

Any special reason to make it separate instead of patching init.c?
Most of codes (e.g. dummy callbacks) are already in init.c.

> struct snd_disconnected_file {
> 	struct file *file;
> 	int (*release) (struct inode *, struct file *);
> 	struct snd_disconnected_file *next;

We can use a standard list here.

> };
> 
> static struct snd_disconnected_file *disconnecting_files;
> static struct file_operations snd_disconnect_f_ops;
> static DEFINE_MUTEX(mutex);
> 
> void snd_disconnect_file(struct file *file, int (*release) (struct inode *, struct file *))
> {
> 	struct snd_disconnected_file *df, **_dfs;
> 	df = kmalloc(sizeof(struct snd_disconnected_file), GFP_ATOMIC);
> 	if (df == NULL)
> 		panic("Atomic allocation failed for snd_disconnected_file!");

IIRC, the reason that snd_card_disconnect() uses GFP_ATOMIC is that
(usb-)disconnection was atomic in the earlier time.
You're using mutex here, hence no reason to allocate with GFP_ATOMIC.

> 	df->file = file;
> 	df->release = release;
> 	df->next = NULL;
> 
> 	mutex_lock(&mutex);
> 	_dfs = &disconnecting_files;
> 	while (*_dfs != NULL)
> 		_dfs = &(*_dfs)->next;
> 	*_dfs = df;

You can add to the item to head :)  The order doesn't matter.

> 	mutex_unlock(&mutex);
> 
> 	{
> 		const struct file_operations *old_f_op = file->f_op;
> 		fops_get(&snd_disconnect_f_ops);
> 		file->f_op = &snd_disconnect_f_ops;
> 		fops_put(old_f_op);

I wonder whether the old release might be called during this
operation.  Then df won't be freed.


> static int snd_disconnect_release(struct inode *inode, struct file *file)
> {
> 	struct snd_disconnected_file *df, **_dfs, **__dfs;
> 	int err = 0;
> 	__dfs = _dfs = &disconnecting_files;
> 
> 	mutex_lock(&mutex);
> 	while ((df = *_dfs))
> 		if (df->file == file) {
> 			*__dfs = df->next;
> 			break;
> 		} else {
> 			__dfs = _dfs;
> 			_dfs = &df->next;
> 		}
> 	mutex_unlock(&mutex);

A standard list would make the code more readable (unless you use too
many underscores ;)


Thanks,

Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Karsten Wiese <annabellesgarden@yahoo.de>
Cc: mingo@elte.hu, alsa-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [Alsa-devel] [PATCH] Reset file->f_op in	snd_card_file_remove(). Take 2
Date: Thu, 05 Oct 2006 12:43:50 +0200	[thread overview]
Message-ID: <s5hmz8boxeh.wl%tiwai@suse.de> (raw)
In-Reply-To: <200610050141.47847.annabellesgarden@yahoo.de>

At Thu, 5 Oct 2006 01:41:47 +0200,
Karsten Wiese wrote:
> 
> Am Mittwoch, 4. Oktober 2006 22:15 schrieb Takashi Iwai:
> > 
> > This looks like a good optoin.  But one thing we have to be careful
> > about is the module counter since the owner is different between the
> > old f_op and disconnect_f_op...
> > 
> here is rc1, will test later.
> Feel free to pick it apart ;-)

Any special reason to make it separate instead of patching init.c?
Most of codes (e.g. dummy callbacks) are already in init.c.

> struct snd_disconnected_file {
> 	struct file *file;
> 	int (*release) (struct inode *, struct file *);
> 	struct snd_disconnected_file *next;

We can use a standard list here.

> };
> 
> static struct snd_disconnected_file *disconnecting_files;
> static struct file_operations snd_disconnect_f_ops;
> static DEFINE_MUTEX(mutex);
> 
> void snd_disconnect_file(struct file *file, int (*release) (struct inode *, struct file *))
> {
> 	struct snd_disconnected_file *df, **_dfs;
> 	df = kmalloc(sizeof(struct snd_disconnected_file), GFP_ATOMIC);
> 	if (df == NULL)
> 		panic("Atomic allocation failed for snd_disconnected_file!");

IIRC, the reason that snd_card_disconnect() uses GFP_ATOMIC is that
(usb-)disconnection was atomic in the earlier time.
You're using mutex here, hence no reason to allocate with GFP_ATOMIC.

> 	df->file = file;
> 	df->release = release;
> 	df->next = NULL;
> 
> 	mutex_lock(&mutex);
> 	_dfs = &disconnecting_files;
> 	while (*_dfs != NULL)
> 		_dfs = &(*_dfs)->next;
> 	*_dfs = df;

You can add to the item to head :)  The order doesn't matter.

> 	mutex_unlock(&mutex);
> 
> 	{
> 		const struct file_operations *old_f_op = file->f_op;
> 		fops_get(&snd_disconnect_f_ops);
> 		file->f_op = &snd_disconnect_f_ops;
> 		fops_put(old_f_op);

I wonder whether the old release might be called during this
operation.  Then df won't be freed.


> static int snd_disconnect_release(struct inode *inode, struct file *file)
> {
> 	struct snd_disconnected_file *df, **_dfs, **__dfs;
> 	int err = 0;
> 	__dfs = _dfs = &disconnecting_files;
> 
> 	mutex_lock(&mutex);
> 	while ((df = *_dfs))
> 		if (df->file == file) {
> 			*__dfs = df->next;
> 			break;
> 		} else {
> 			__dfs = _dfs;
> 			_dfs = &df->next;
> 		}
> 	mutex_unlock(&mutex);

A standard list would make the code more readable (unless you use too
many underscores ;)


Thanks,

Takashi

  reply	other threads:[~2006-10-05 10:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-28 20:28 [PATCH] Reset file->f_op in snd_card_file_remove(). Take 2 Karsten Wiese
2006-09-28 20:28 ` Karsten Wiese
2006-09-29 10:48 ` Takashi Iwai
2006-09-29 10:48   ` Takashi Iwai
2006-09-29 12:29   ` Karsten Wiese
2006-09-29 12:29     ` Karsten Wiese
2006-09-29 12:26     ` Ingo Molnar
2006-09-29 12:45     ` Takashi Iwai
2006-09-29 12:45       ` Takashi Iwai
2006-10-01 18:29       ` Karsten Wiese
2006-10-01 18:29         ` Karsten Wiese
2006-10-04  9:22         ` Takashi Iwai
2006-10-04  9:22           ` Takashi Iwai
2006-10-04 10:47           ` Karsten Wiese
2006-10-04 14:18             ` Takashi Iwai
2006-10-04 15:36               ` Karsten Wiese
2006-10-04 15:36                 ` Karsten Wiese
2006-10-04 15:57                 ` Takashi Iwai
2006-10-04 15:57                   ` Takashi Iwai
2006-10-04 20:01                   ` Karsten Wiese
2006-10-04 20:01                     ` Karsten Wiese
2006-10-04 20:15                     ` Takashi Iwai
2006-10-04 20:15                       ` Takashi Iwai
2006-10-04 23:41                       ` Karsten Wiese
2006-10-04 23:41                         ` Karsten Wiese
2006-10-05 10:43                         ` Takashi Iwai [this message]
2006-10-05 10:43                           ` [Alsa-devel] " Takashi Iwai
2006-10-05 11:33                           ` [PATCH] Reset file->f_op in snd_card_file_remove (). " Karsten Wiese
2006-10-05 11:33                             ` [Alsa-devel] [PATCH] Reset file->f_op in snd_card_file_remove(). " Karsten Wiese
2006-10-05 14:12                             ` [PATCH] Reset file->f_op in snd_card_file_remove (). " Karsten Wiese
2006-10-05 14:12                               ` [Alsa-devel] [PATCH] Reset file->f_op in snd_card_file_remove(). " Karsten Wiese

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=s5hmz8boxeh.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=annabellesgarden@yahoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.