RFE: is it necessary for kernel reply to auditd with block mode in function netlink_unicast when auditd service is stopping

[e06620227]

When the auditd service is stopped，it will call audit_set_pid(fd, 0, WAIT_NO) and do not process reply messages

int audit_set_pid(int fd, uint32_t pid, rep_wait_t wmode)
{
struct audit_status s;
struct audit_reply rep;
struct pollfd pfd[1];
int rc;

memset(&s, 0, sizeof(s));
s.mask    = AUDIT_STATUS_PID;
s.pid     = pid;
rc = audit_send(fd, AUDIT_SET, &s, sizeof(s));
if (rc < 0) {
	audit_msg(audit_priority(errno), 
		"Error setting audit daemon pid (%s)", 
		strerror(-rc));
	return rc;
}
if (wmode == WAIT_NO)
	return 1;

/* Now we'll see if there's any reply message. This only
       happens on error. It is not fatal if there is no message.
   As a matter of fact, we don't do anything with the message
   besides gobble it. */
pfd[0].fd = fd;
pfd[0].events = POLLIN;
do {
	rc = poll(pfd, 1, 100);	/* .1 second */
} while (rc < 0 && errno == EINTR);

(void)audit_get_reply(fd, &rep, GET_REPLY_NONBLOCKING, 0);
return 1;

}

so why kernel reply to auditd with block mode in function netlink_unicast？ When the audit event load is heavy, netlink_attachskb will be scheduled to hang，the auditd has stopped to consume recvbuf.
netlink_unicast(sk, skb, portid, 0) -> netlink_unicast(sk, skb, portid, 1) Is it more reasonable？

audit_receive_msg->audit_replace->auditd_send_unicast_skb->netlink_unicast(sk, skb, portid, 0)->netlink_attachskb

[e06620227]

linux-audit/audit-userspace#204
@pcmoore @rgbriggs @the-M

[pcmoore]

Who is @the-M ?

Anyway, I think most of us are rather busy at the moment dealing with other audit related issues. You can try posting to the the audit mailing list, but most of my audit cycles at the moment are busy dealing with other audit issues that are a bit more critical.

[rgbriggs]

On 2021-06-11 10:43, Paul Moore wrote: Who is @the-M ?

I think it was intended to be Ondrej Moris. https://github.com/The-Mule