Re: seq_file API strangeness

[viro]

On Fri, Nov 14, 2003 at 08:55:48PM +0000, Tigran Aivazian wrote:
> In the ->open() method I allocate a seq->private like this:
> 
>   err = seq_open(file, sop);
>   if (!err) {
> 	struct seq_file *m = file->private_data;
> 
> 	m->private = kmalloc(sizeof(struct ctask), GFP_KERNEL);
>         if (!m->private) {
>                         kfree(file->private_data);
>                         return -ENOMEM;
>         }
>   }
> 
> Now, freeing the structure that I did not allocate (file->private_data 
> allocated in seq_open()) is not nice. But calling seq_release() from 
> ->open() method is not nice either (different arguments, namely 'inode'

I beg your pardon?  What different arguments?

->open() gets struct inode * and struct file *
->release() gets exactly the same.
seq_release() is what you use as ->release()

What's the problem?

> and also m->buf is NULL at that point, although I believe kfree(NULL) is 
> not illegal).

Of course it is not illegal.  Moreover, if you just do open() immediately
followed by close(), you won't get non-NULL ->buf at all.  It's a perfectly
normal situation and seq_release() can handle it - no problems with that.

> What do you think?

	if (!m->private) {
		seq_release(inode, file);
		return -ENOMEM;
	}

Same as e.g. fs/proc/base.c does in similar situation (see mounts_open()).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/