Messages in this thread | | | Date | Fri, 14 Nov 2003 21:19:13 +0000 | From | viro@parcelfa ... | Subject | Re: seq_file API strangeness |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |