From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Lucas C. Villa Real" Subject: check_ack() Date: Fri, 21 Nov 2008 04:30:53 -0200 Message-ID: <2c03f9590811202230x5daf2ea8i3d7aa0aedb1bcf47@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mAL6V41V018872 for ; Fri, 21 Nov 2008 01:31:04 -0500 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id mAL6Urxh018542 for ; Fri, 21 Nov 2008 01:30:53 -0500 Received: by ey-out-2122.google.com with SMTP id 4so298262eyf.39 for ; Thu, 20 Nov 2008 22:30:53 -0800 (PST) Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hi, guys! I have a question regarding the use of check_ack() in audit_send(). Every message sent from auditd to the kernel through audit_send() is flagged with NLM_F_ACK. That flag tells the kernel to reply with an ACK, which will then be expected to be read by check_ack(), right after audit_send's call to sendto(). check_ack() just attempts to read nonblocking and, if it succeeds doing so, it's guaranteed that the kernel received our message. However, since netlink is a connectionless socket, once cannot infer that the lack of an ACK means that the kernel didn't receive that message. Similarly, in a very stressed system, one can just get -ENOBUFS when attempting to get a reply, even though sendto() succeeded sending the original message. So, at least in a scenario where Audit is a key component and performance matters, wouldn't it make sense to just remove NLM_F_ACK from outgoing messages and just let audit_send() use the return value from sendto() to tell if the message has been sent instead? I'm planning to test this change in a pretty I/O intensive server over the next week, but I'd really like to hear your comments on this before I proceed. Thank you very much! Lucas