Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262051AbTKOTyx (ORCPT ); Sat, 15 Nov 2003 14:54:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262061AbTKOTyx (ORCPT ); Sat, 15 Nov 2003 14:54:53 -0500 Received: from userel174.dsl.pipex.com ([62.188.199.174]:24455 "EHLO einstein.homenet") by vger.kernel.org with ESMTP id S262051AbTKOTyo (ORCPT ); Sat, 15 Nov 2003 14:54:44 -0500 Date: Sat, 15 Nov 2003 19:54:48 +0000 (GMT) From: Tigran Aivazian X-X-Sender: tigran@einstein.homenet To: viro@parcelfarce.linux.theplanet.co.uk cc: Harald Welte , Subject: Re: seq_file API strangeness In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2369 Lines: 68 Ah, I know why I thought they took different arguments! Because I was creating two files --- binary and ascii versions and they shared the same "open_common" routine which didn't need an 'inode' so I was only passing 'file' and appropriate 'seq_operations' pointer to it :) On Sat, 15 Nov 2003, Tigran Aivazian wrote: > 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/