diff options
author | David Woodhouse <dwmw2@shinybook.infradead.org> | 2005-07-02 14:08:48 +0100 |
---|---|---|
committer | David Woodhouse <dwmw2@shinybook.infradead.org> | 2005-07-02 14:08:48 +0100 |
commit | ac4cec443a80bfde829516e7a7db10f7325aa528 (patch) | |
tree | 599801be12aa415d1c734cde37b1c2378fc6fe98 /include/asm-ppc64/unistd.h | |
parent | 7b430437c0de81681ecfa8efa8f55823df733529 (diff) | |
download | kernel_samsung_smdk4412-ac4cec443a80bfde829516e7a7db10f7325aa528.zip kernel_samsung_smdk4412-ac4cec443a80bfde829516e7a7db10f7325aa528.tar.gz kernel_samsung_smdk4412-ac4cec443a80bfde829516e7a7db10f7325aa528.tar.bz2 |
AUDIT: Stop waiting for backlog after audit_panic() happens
We force a rate-limit on auditable events by making them wait for space
on the backlog queue. However, if auditd really is AWOL then this could
potentially bring the entire system to a halt, depending on the audit
rules in effect.
Firstly, make sure the wait time is honoured correctly -- it's the
maximum time the process should wait, rather than the time to wait
_each_ time round the loop. We were getting re-woken _each_ time a
packet was dequeued, and the timeout was being restarted each time.
Secondly, reset the wait time after audit_panic() is called. In general
this will be reset to zero, to allow progress to be made. If the system
is configured to _actually_ panic on audit_panic() then that will
already have happened; otherwise we know that audit records are being
lost anyway.
These two tunables can't be exposed via AUDIT_GET and AUDIT_SET because
those aren't particularly well-designed. It probably should have been
done by sysctls or sysfs anyway -- one for a later patch.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Diffstat (limited to 'include/asm-ppc64/unistd.h')
0 files changed, 0 insertions, 0 deletions