On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
I also tried to extend Cong Wang's idea to attempt to proactively
respond to a
NETLINK_URELEASE on the audit_sock and reset it, but ran into a locking error
stack dump using mutex_lock(&audit_cmd_mutex) in the notifier callback.
Eliminating the lock since the sock is dead anways eliminates the error.
Is it safe? I'll resubmit if this looks remotely sane. Meanwhile I'll try to
get the test case to compile.
It doesn't look safe, because 'audit_sock', 'audit_nlk_portid' and
'audit_pid'
are updated as a whole and race between audit_receive_msg() and
NETLINK_URELEASE.
@@ -1167,10 +1190,14 @@ static void __net_exit audit_net_exit(struct
net *net)
{
struct audit_net *aunet = net_generic(net, audit_net_id);
struct sock *sock = aunet->nlsk;
+
+ mutex_lock(&audit_cmd_mutex);
if (sock == audit_sock) {
audit_pid = 0;
+ audit_nlk_portid = 0;
audit_sock = NULL;
}
+ mutex_unlock(&audit_cmd_mutex);
If you decide to use NETLINK_URELEASE notifier, the above piece is no
longer needed, the net_exit path simply releases a refcnt.