handling disk full

Chris Wright chrisw at osdl.org
Wed Dec 15 18:53:33 UTC 2004


* Mounir Bsaibes (bsaibes at us.ibm.com) 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.

Look at audit_log_start callers.  They include avc_perm, which can happen
in interrupt context.  Notice audit_log_start() is already coded to be
called from nearly any context, it uses _irq versions of spinlock and
does GFP_ATOMIC allocations.

> 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. 

The best you could do is wait until syscall exit and queue up processes
then.  The action will have taken place, but the caller wouldn't get
scheduled until it's awoken by audit system.  (This doesn't help for the
case of creating something that another process could then use, as it
will exist, and the other process's access to object may not be an
auditable event).

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net




More information about the Linux-audit mailing list