handling disk full

[Stephen Smalley]

On Wed, 2004-12-15 at 13:40, Mounir Bsaibes wrote:
> We are talking about 2 different things: 1) handling disk full 2)
> suspending the process whenever there are no kernel resources.
> 
> 1) For handling disk full I am doing the following:
> Whenever the disk full (or log reached its limit)  is detected the
> auditd sends an AUDIT_SUSPEND message to the kernel. On receipt of
> this message the kernel will set a flag "disk_full_flag".   If this
> disk_full_flag  is set audit_log_start will call audit_suspend to
> queue the process in a wait queue. Whenever the disk_full_flag is
> reset all the processes in the wait queue will be rescheduled.
> 
> 2) For suspending the process whenever there are no kernel resources:
> I was thinking of using sigsuspend whenever audit_log_lost is called
> depending on the "failure flag". The failure flag currently can be set
> ,only, to: do nothing, print a message or panic.  I was thinking to
> add a fourth option to this flag to suspend the processes.
> sigsuspend puts the process in the TASK_INTERRUPTIBLE state, the
> process will only wake up when a nonignored, nonblocked signal is sent
> to it. From the dicussion so far this may not be a good way to go
> about solving this requirement, specially if the process is holding
> locks or whatever. I need to either add to this solution or come up
> with a different one. 

I'm not entirely clear on the distinction above (i.e. why you don't just
handle both situations in the same manner).  But in any event, the
processing you describe can only safely be done from either:
a) audit_syscall_exit, or
b) some new audit_log* functions that are explicitly identified as
potentially blocking.

You can't change the existing audit_log* functions or core helper
functions used by them to suddenly start blocking (or you at least have
to allow a flag to preserve the current non-blocking behavior), because
current users of the audit system rely on the ability to call audit_log*
from any context.  This is similar to printk, which also strives to be
useable from any context.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency