Re: closefd: closes a file of any process

From: Tigran Aivazian (tigran@veritas.com)
Date: Sat Jun 24 2000 - 05:11:37 EST


On Fri, 23 Jun 2000, Martin Mares wrote:

> Hello!
>
> > Then the first thing that occur to you is to forcibly close an fd. You
> > write some code and investigate until you discover that it *IS*
> > impossible. Then you come up with an idea of implementing a special
> > filesystem 'nullfs' where you shift the open file to, instead of closing
> > it. Any subsequent io on this fd gives EIO.
>
> I didn't look at the actual code yet, but isn't it possible to just
> replace all inodes by invalid inodes (via make_bad_inode()) instead
> of forcibly closing all the related FD's?
>

neither of this is possible (*sigh* see, this is why I delayed releasing
nullfs - clever people like you generate very interesting discussion but I
am *very* busy (on a different project) for any discussions antil mid-July
:)

the reason make_bad_inode() isn't enough is that:

a) you need to replace file->f_op also

b) you need to balance the reference counts carefully, i.e. really you
should move any references *out* of this sb/mnt pair (or just mnt if more
than one) into another sb/mnt pair.

c) doesn't apply to chdir/chroot

nullfs can be thought of as extension to make_bad_inode() (which it uses,
of course, no point in duplicating bad_inode_ops/bad_file_ops) but more in
the direction of "move a VFS concept of inode into another filesystem,
release fs-specific knowledge of this inode, and associate a new namespace
element with it which is not reachable from userspace).

Al Viro's recent infrastructure of in-kernel-mounted (kern_mount())
filesystems provides excellent framework for all this.

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:04 EST