Re: Re: closefd: closes a file of any process

What about a way to tell kernel to disable clone() for all non-root 
processes ?

So your fuser -k does this:

 1. disable clone
 2. kill 
 3. wait for kill to complete
 4. reenable clone

                      Vladimir Dergachev

Tigran Aivazian <[e-mail]> wrote:
> On Wed, 28 Jun 2000, Werner Almesberger wrote:> The basic assumption is still that
> the program didn't really need to access the file in the first place.
> 

the basic assumption, or rather I should say a "typical scenario" is this:

a) userspace signals all important applications ("important" - that for
which integrity customer pays for) to terminate. They terminate cleanly -
if not, that is their own bug and should be fixed by the app vendor - in
the meantime these "important" apps will be treated as "unimportant" - see
b) below.

b) 3rd party "unimportant" applications, however, still keep the
filesystem busy by either:

  o open files

  o mmapped (but possibly closed) files
 
  o cwd

  o root

  o passing fd currently in transit ("ACM_RIGHTS datagram in flight")

. So, the userspace does a couple of "fuser -k" but the applications are
so nasty that they come in parent-child relationship and monitor each
others death and fork() quickly enough to keep the filesystem busy however
fast you shoot them with fuser -k. You can write a simple example "nasty"
app" like this easily.

c) so, the kernel must intervene. Now let's look at the line you typed
below:

> So I'm still wondering if a clean exit/kill wouldn't be better in almost
> all cases.

If you wish to select who to kill you will take a tasklist_lock for read
because you need to do for_each_task and examine each tasks filesystem
state. So, you select who needs killing and signal it. In order for a
signal to be handled you need to schedule() and thus drop the spinlocks
(not just tasklist_lock but also various others, e.g. files_lock) and goto
before for_each_task. Dropping the spinlocks gives the "nasty apps" an
opportunity to create more work for you so the loop will never finish in
the worst case.

Therefore killing tasks, i.e. implementing "fuser -k in the kernel" is not
a solution, imho.

Regards,
Tigran