Re: filesystem signal handling

[David Woodhouse <dwmw2@infradead.org>]

On Tue, 2004-04-27 at 15:29 -0500, Steve French wrote:
> I noticed that the ramfs and libfs code do not have special handling of
> signals (checking for signal_pending, returning or handling ERESTARTSYS
> or EINTR).   
> 
> Is it permitted for a filesystem to mask signals temporarily across most
> fs calls and simply let the higher layers handle checking for
> signal_pending (other than using the existing of a signal_pending to
> shorten schedule_timeouts so the app would not wait as long on errors)?

NFS does this. It's fairly ugly. What would be a _lot_ nicer if we could
have something in the task_struct which is vaguely reminiscent of
preempt_count, only it counts the number of reasons why this task cannot
receive signals. So instead of using the TASK_INTERRUPTIBLE and
TASK_UNINTERRUPTIBLE states to make the decision, we'd look at the
task's uninterruptible_count instead. 

That way, we can provide functions, including the ones you mention as
dangerous, which do the right thing _both_ when called from a function
which cannot tolerate signals, and when called from a function which
_can_ perform the necessary cleanup. Without screwing with the signal
masks. 

(In fact, I think it would be useful also to have a way of saying that
_fatal_ signals should be allowed, but not signals with a handler. This
would be useful in, e.g., sys_read() and sys_write().)

-- 
dwmw2