Bug 14505 - Linux kernel needs an API for forcibly closing open file descriptors, i.e. revoke (2) system call
Summary: Linux kernel needs an API for forcibly closing open file descriptors, i.e. re...
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: VFS (show other bugs)
Hardware: All Linux
: P1 enhancement
Assignee: fs_vfs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-29 08:01 UTC by Artem S. Tashkinov
Modified: 2020-08-05 10:05 UTC (History)
5 users (show)

See Also:
Kernel Version: All known (inc 3.5rc2)
Tree: Mainline
Regression: No


Attachments

Description Artem S. Tashkinov 2009-10-29 08:01:24 UTC
In many situations you need e.g. umount a file system and you do NOT want to close applications which have files open on this file system. Currently there's no way to umount such an FS unless you close all those "offending" applications.

This is absolutely inconvenient, because

1) In a multiuser environment you may not want to close applications running under a different user account - you want to keep them running.

2) Finding such applications should not be a concern for a root user (yes, I known about fuser).

There must be no concern about "lost" file descriptors because applications must have a logic to deal with such a situation (and I am quite sure most applications have it).
Comment 1 Alexey Dobriyan 2009-11-16 15:07:56 UTC
neverending revoke(2) story

last attempt was broken by necessity to audit every ioctl handler wrt
this behaviour, IIRC
Comment 2 Artem S. Tashkinov 2009-11-16 15:15:49 UTC
Alexey, could you please shed some light on this topic? It seems like some BSD's have this system call, but I don't see it neither in linux nor in glibc.
Comment 3 Alexey Dobriyan 2009-11-16 15:18:17 UTC
search linux-kernel archives for "revoke"
several attempts with different degrees of brokeness
Comment 4 Artem S. Tashkinov 2009-11-16 15:42:47 UTC
Hm, I've found a long thread here http://lkml.org/lkml/2009/6/1/395 and it seems like it ended to no effect. (google for [PATCH 04/23] vfs: Introduce infrastructure for revoking a file )

OK, let's wait for a better approach - I'm not a developer/programmer, so I can only hope Linux will have a revoke (2) system call (which is a must nowadays, IMO).
Comment 5 Marshel Abraham 2013-05-30 08:37:59 UTC
A better solution is avaliable from Al viro....I got stuck up in this bug for some time

http://lwn.net/Articles/546540/
Comment 6 Artem S. Tashkinov 2013-05-30 12:33:04 UTC
It's not yet a solution, it's just a proposal and from what it looks like, it seems like half of the kernel needs to be rewritten from scratch in order to accommodate this call.
Comment 7 Marshel Abraham 2013-05-30 13:57:50 UTC
Yeah I m just one patch old in hacking..desperate to get one more in...I think i landed up in the wrong place...:P
Comment 8 GYt2bW 2019-05-06 21:06:47 UTC
Is maybe `umount --lazy` (perhaps even coupled with `--recursive` if necessary) doing wonders for anyone else?  


```
      -l, --lazy
              Lazy unmount.  Detach the filesystem  from  the  file  hierarchy
              now,  and  clean up all references to this filesystem as soon as
              it is not busy anymore.

              A system reboot would be expected in near future if you're going
              to  use  this  option for network filesystem or local filesystem
              with submounts.  The recommended use-case for umount  -l  is  to
              prevent  hangs  on  shutdown due to an unreachable network share
              where a normal umount will hang due to a downed server or a net‐
              work partition. Remounts of the share will not be possible.

       -R, --recursive
              Recursively  unmount  each  specified  directory.  Recursion for
              each directory will stop if any unmount operation in  the  chain
              fails  for  any reason.  The relationship between mountpoints is
              determined by /proc/self/mountinfo entries.  The filesystem must
              be  specified  by mountpoint path; a recursive unmount by device
              name (or UUID) is unsupported.
```
Comment 9 Artem S. Tashkinov 2019-05-06 22:00:32 UTC
(In reply to howaboutsynergy from comment #8)
> Is maybe `umount --lazy` (perhaps even coupled with `--recursive` if
> necessary) doing wonders for anyone else?  
> 

This system call is _not_ about being able to unmount devices.
Comment 10 Artem S. Tashkinov 2020-08-05 10:05:03 UTC
Is this the same or not?

http://lkml.iu.edu/hypermail/linux/kernel/2008.0/02649.html
https://lkml.org/lkml/2020/8/4/385

And how come the patch is so small?

Note You need to log in before you can comment on or make changes to this bug.