Re: 2.4 Q: list of open files per inode?

Re: 2.4 Q: list of open files per inode?

[Jacob A]

Al,

I'm using the open/close call as a way for processes to register/unregister with a watchdog driver that I'm writing.
I thought that I can save the housekeeping within the driver, but it looks like It would be easier just to maintain my own list
and be done with it.

Jacob

----- Original Message ----
From: Al Viro <viro@ftp.linux.org.uk>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: Jacob A <jacoba51-tmp@yahoo.com>; linux-kernel@vger.kernel.org
Sent: Thursday, July 19, 2007 7:38:10 PM
Subject: Re: 2.4 Q: list of open files per inode?

On Thu, Jul 19, 2007 at 01:41:03PM +0200, Jan Engelhardt wrote:
> 
> On Jul 19 2007 02:01, Jacob A wrote:
> >
> > How can a device driver go over the  list of all the files that are open on a
> > specific inode instance?
> 
> pseudo-code:
> 
> task_list_lock;
> for each process; do
>     lock_fdtable;
>     for each filedescriptor; do
>         do_something(fd->file_ptr);
>     unlock_fdtable;
> task_list_unlock;

Not again...

There are other things that can keep file open.  SCM_RIGHTS, references
held by syscall in progress, etc., etc.

The real question is why does driver want to do that?  Details, please...

Re: 2.4 Q: list of open files per inode?

[Jan Engelhardt]

On Jul 22 2007 04:39, Jacob A wrote:

>I'm using the open/close call as a way for processes to
>register/unregister with a watchdog driver that I'm writing. I
>thought that I can save the housekeeping within the driver, but it
>looks like It would be easier just to maintain my own list and be
>done with it.

Sounds a bit wrong. _What_ exactly do you want to keep?


	Jan
-- 

Re: 2.4 Q: list of open files per inode?

[Al Viro]

On Sun, Jul 22, 2007 at 04:39:14AM -0700, Jacob A wrote:
> Al,
> 
> I'm using the open/close call as a way for processes to register/unregister with a watchdog driver that I'm writing.
> I thought that I can save the housekeeping within the driver, but it looks like It would be easier just to maintain my own list
> and be done with it.

What do you mean "register with a watchdog driver"?  The process that
had opened file might be long gone while the file remains open...

What kind of information do you keep for each struct file?

PS: stop top-posting

Re: 2.4 Q: list of open files per inode?

[Jacob A]

Ah, yes, this was my intention, to keep the state in filp->private_data.
But then at a timer routine I wanted to go over all the filps associated with the device
and check/modify the state. That's why I needed the open files list.
-Jacob

----- Original Message ----
From: Jan Engelhardt <jengelh@computergmbh.de>
To: Jacob A <jacoba51-tmp@yahoo.com>
Cc: Al Viro <viro@ftp.linux.org.uk>; linux-kernel@vger.kernel.org
Sent: Sunday, July 22, 2007 3:28:30 PM
Subject: Re: 2.4 Q: list of open files per inode?


On Jul 22 2007 05:26, Jacob A wrote:

>I want to keep an internal state per each registration instance, and I opted
>to use open() as the registration mechanism.

So why not just store it in filp->private_data?



    Jan
-- 



>

    Jan
-- 

Re: 2.4 Q: list of open files per inode?

[Jan Engelhardt]

On Jul 22 2007 05:45, Jacob A wrote:
>
>Ah, yes, this was my intention, to keep the state in filp->private_data.
>But then at a timer routine I wanted to go over all the filps associated with the device
>and check/modify the state. That's why I needed the open files list.

No. For each private_data that you allocate, create a linked list
that also has them. In other words:


struct mystuff {
	struct list_head list;
	int other_fluff;
};

int mydriver_open()
{
	struct mystuff *pd = kmalloc(...);
	filp->private_data = pd;
	list_add(&pd->list);
}

int mydriver_close()
{
	struct mystuff *pd = filp->private_data;
	list_del(&pd->list);
	free(pd);
}

Simple as that. *Of course* this requires that the file descriptor remains
open. But that should not be a problem, would it?


    Jan
-- 



>

    Jan
-- 



>

	Jan
-- 

Re: 2.4 Q: list of open files per inode?

[Al Viro]

On Sun, Jul 22, 2007 at 05:23:22PM +0300, Jacob Avraham wrote:
> > {
> > 	struct mystuff *pd = filp->private_data;
> > 	list_del(&pd->list);
> > 	free(pd);
> > }
> > 
> > Simple as that. *Of course* this requires that the file descriptor remains
> > open. But that should not be a problem, would it?

First of all, that's obviously racy (list manipulations without any
exclusion *or* preventing aforementioned timer running while you do
it).

More important part is that stuff put into your private_data would
better remain valid through the lifetime of opened file.  In particular,
you _can't_ expect that process that had opened the file in question
is still alive.
 
> I ended up implementing my own list (similar to the above), so now the question is more theoretical.
> BTW, does 2.6 has an easy way to get from an inode to all the open fds?

Same situation.

Re: 2.4 Q: list of open files per inode?

[Jacob A]

I want to keep an internal state per each registration instance, and I opted to use open() as the registration mechanism.
-Jacob

----- Original Message ----
From: Jan Engelhardt <jengelh@computergmbh.de>
To: Jacob A <jacoba51-tmp@yahoo.com>
Cc: Al Viro <viro@ftp.linux.org.uk>; linux-kernel@vger.kernel.org
Sent: Sunday, July 22, 2007 2:58:18 PM
Subject: Re: 2.4 Q: list of open files per inode?


On Jul 22 2007 04:39, Jacob A wrote:

>I'm using the open/close call as a way for processes to
>register/unregister with a watchdog driver that I'm writing. I
>thought that I can save the housekeeping within the driver, but it
>looks like It would be easier just to maintain my own list and be
>done with it.

Sounds a bit wrong. _What_ exactly do you want to keep?


    Jan
-- 

Re: 2.4 Q: list of open files per inode?

[Jan Engelhardt]

On Jul 22 2007 05:26, Jacob A wrote:

>I want to keep an internal state per each registration instance, and I opted
>to use open() as the registration mechanism.

So why not just store it in filp->private_data?



    Jan
-- 



>

	Jan
-- 

2.4 Q: list of open files per inode?

[Jacob A]

 How can a device driver go over the  list of all the files that are open on a specific inode  instance?

I'd like to avoid doing my own housekeeping.



 The question is about 2.4  kernel.

  

 Thanks,

  

 Jacob

Re: 2.4 Q: list of open files per inode?

[Jan Engelhardt]

On Jul 19 2007 02:01, Jacob A wrote:
>
> How can a device driver go over the  list of all the files that are open on a
> specific inode instance?

pseudo-code:

task_list_lock;
for each process; do
	lock_fdtable;
	for each filedescriptor; do
		do_something(fd->file_ptr);
	unlock_fdtable;
task_list_unlock;


Though, you really don't want to do that.



	Jan
-- 

Re: 2.4 Q: list of open files per inode?

[Al Viro]

On Thu, Jul 19, 2007 at 01:41:03PM +0200, Jan Engelhardt wrote:
> 
> On Jul 19 2007 02:01, Jacob A wrote:
> >
> > How can a device driver go over the  list of all the files that are open on a
> > specific inode instance?
> 
> pseudo-code:
> 
> task_list_lock;
> for each process; do
> 	lock_fdtable;
> 	for each filedescriptor; do
> 		do_something(fd->file_ptr);
> 	unlock_fdtable;
> task_list_unlock;

Not again...

There are other things that can keep file open.  SCM_RIGHTS, references
held by syscall in progress, etc., etc.

The real question is why does driver want to do that?  Details, please...