Bug 1296189
| Summary: | RFE: audit default backlog_wait_time setting | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steve Grubb <sgrubb> |
| Component: | kernel | Assignee: | Paul Moore <pmoore> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, rbriggs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-12-02 19:26:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Steve Grubb
2016-01-06 14:47:16 UTC
I would be tempted to close this as a duplicate of bz1129013. If it is stuck, there is a reason why, and shortening the timeout won't fix that. Okay, I'll buy that reasoning, but since BZ #1129013 is opened for RHEL6, and currently unresolved, let's leave this BZ open. Once we have resolved BZ #1129013 and merged the fix upstream we can mark this as UPSTREAM. One question about bz1129013, none of the loops use audit_pid to see if its even valid to wait on auditd. Shouldn't they only wait on auditd if there is an auditd? IOW - while (audit_backlog_limit + while (audit_backlog_limit && audit_pid && skb_queue_len(&audit_skb_queue) > audit_backlog_limit + reserve) { (In reply to Steve Grubb from comment #3) > One question about bz1129013, none of the loops use audit_pid to see if its > even valid to wait on auditd. Shouldn't they only wait on auditd if there is > an auditd? IOW > > - while (audit_backlog_limit > + while (audit_backlog_limit && audit_pid > && skb_queue_len(&audit_skb_queue) > audit_backlog_limit + reserve) { I attempted to address some of this in the case where it goes away while waiting with: [RFC PATCH 6/7] audit: wake up audit_backlog_wait queue when auditd goes away. https://www.redhat.com/archives/linux-audit/2015-October/msg00074.html and [RFC PATCH 7/7] audit: wake up kauditd_thread after auditd registers https://www.redhat.com/archives/linux-audit/2015-October/msg00074.html pmoore's reply: https://www.redhat.com/archives/linux-audit/2015-November/msg00028.html I'll think about this one, but that might address another case I hadn't considered... (In reply to Richard Guy Briggs from comment #4) > (In reply to Steve Grubb from comment #3) > > One question about bz1129013, none of the loops use audit_pid to see if its > > even valid to wait on auditd. Shouldn't they only wait on auditd if there is > > an auditd? IOW > > > > - while (audit_backlog_limit > > + while (audit_backlog_limit && audit_pid > > && skb_queue_len(&audit_skb_queue) > audit_backlog_limit + reserve) { > > I attempted to address some of this in the case where it goes away while > waiting with: > [RFC PATCH 6/7] audit: wake up audit_backlog_wait queue when auditd goes > away. > https://www.redhat.com/archives/linux-audit/2015-October/msg00074.html > and > [RFC PATCH 7/7] audit: wake up kauditd_thread after auditd registers > https://www.redhat.com/archives/linux-audit/2015-October/msg00074.html oops, wrong link, here's the right one: https://www.redhat.com/archives/linux-audit/2015-October/msg00075.html > pmoore's reply: > https://www.redhat.com/archives/linux-audit/2015-November/msg00028.html > > I'll think about this one, but that might address another case I hadn't > considered... So where do we stand on this at present? Still waiting in upstream resolution to bz 1129013 . Closing this out as we have made some substantial changes upstream for Linux v4.10 which should improve the behavior of the backlog under load. * https://github.com/linux-audit/audit-kernel/issues/23 |