lkml.org 
[lkml]   [2003]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.121 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site