Re: filesystem signal handling

[David Woodhouse <dwmw2@infradead.org>]

On Wed, 2004-04-28 at 22:53 -0400, Trond Myklebust wrote:
> One of the main points of playing with the sigmask in the first place is
> that interrupting an operation in the middle of the RPC call leaves
> various attribute/data caches in an incoherent state, and so is in
> general bad practice.

We can generalise that. The main reason for blocking signals -- be it by
using TASK_UNINTERRUPTIBLE, manipulating the sigmask, or some
hypothetical 'uninterruptible_count' in the task_struct, is that in some
places we either can't or don't want to clean up properly if a signal
happens. Sometimes that requirement comes all the way from userspace
(e.g. expected semantics of sys_read() and short reads)

In those problematic cases, we often call other functions which may
sleep any may potentially be interrupted -- since we can't handle that,
we obviously require them _not_ to be interrupted. But making those
functions use TASK_UNINTERRUPTIBLE means that they can't be interrupted
even when called by other callers which _could_ clean up after
themselves -- unless we do something horrid like passing a flag all the
way down to say what sleep state should be used. 

The advantage of doing it with the latter two methods mentioned above is
that the 'problematic' routine can make that decision for itself and set
some state, and then the routines which it calls don't need to care.
They just _don't_ get interrupted when they're called from a function
which cannot handle receiving -EINTR.

> We certainly don't want something like a poorly
> coded application that generates the occasional SIGSEGV or SIGBUS (or
> even a well-coded one that uses timers + SIGALRM!) to screw up the
> cached data/metadata for everyone else.

If that's a possible outcome, why doesn't that happen with uncaught
SIGINT? 

-- 
dwmw2