Linux-kernel mailing list archive 2000-26,: Re: closefd: closes a file of any process

# Re: closefd: closes a file of any process

almesber@lrc.di.epfl.ch
Wed, 28 Jun 2000 17:49:16 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: lord@sgi.com: "Re: kmap_kiobuf()"
- Previous message: Daniel Summer: "RE: disk performance still wrecked in 2.4!"

Tigran Aivazian wrote:
> to a different inode. The real inode is released. Do you think this is the
> wrong direction too?

What I don't quite understand about your close mechanism is for what type
of situation it is intended. It seems to me that only very few programs
can be expected to continue correct operation if you just break their
file descriptors. If in doubt, you have to exit or kill the program
anyway.

The only obvious exceptions are programs that are known not to do anything
with files anyway (so you can take away root, cwd, and std*), and programs
that do some background jobs and don't really need to interact over their
tty (take away std*). Is this what you're after ?

What your approach doesn't seem to solve is the much nastier problem of
hanging somewhere in the kernel in an uninterruptible sleep on something
underneath a file descriptor. Obviously, trying to close it can't work in
this case either.

One way to solve this is to find any cases where there is an
uninterruptible sleep that could be safely turned into an interruptible
one. In cases where interruption is impossible either because the API
doesn't allow it (e.g. getpid(2)), or because interruption is not
acceptable for temporary failures and the kernel can't distinguish them
from permanent failures (e.g. some important metadata updates on a failing
disk), one could maybe introduce some SIGKILL_DESPERATELY (*) which gets
checked even in an uninterruptible sleep and takes whatever desperate
action is necessary in that case. Then, common problem spots could be
converted accordingly.

Of course, part of the problem may also be that NFS doesn't offer enough
granularity, i.e. you either get a rigidly uninterruptible system or
something fragile that happily aborts operations even if you brush ^C by
accident. Again, something like SIGKILL_DESPERATELY would help here.

(* perferrably the whole name would have to be typed into kill. It makes
me sick whenever I see some id^Hnsufficiently educated user kill -9
everything in sight just because somebody told them that kill -9
always works.)

- Werner

    --
      _________________________________________________________________________
     / Werner Almesberger, ICA, EPFL, CH       werner.almesberger@ica.epfl.ch /
    /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

    -
    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/

- Next message: lord@sgi.com: "Re: kmap_kiobuf()"
- Previous message: Daniel Summer: "RE: disk performance still wrecked in 2.4!"