Messages in this thread | | | Date | Sat, 15 Nov 2003 19:52:00 +0000 (GMT) | From | Tigran Aivazian <> | Subject | Re: seq_file API strangeness |
| |
Hi Al,
Yes, you are right, thank you. I don't know why I thought open/release took different arguments. Yes, calling seq_release(inode,file) is the right way, I will change my code.
Kind regards Tigran
On Fri, 14 Nov 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:
> 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/
| |