Re: panic: rm_rlock: recursed on non-recursive rmlock mac_policy_rm @ /usr/src/sys/security/mac/mac_framework.c:198

On Sat, Sep 28, 2013 at 03:41:58PM +0400, Andrej Zverev wrote:
>  Hello,
> 
> I see following panic of 10.0-ALPHA3 r255906
> 
> (kgdb) #0  doadump (textdump=0) at pcpu.h:232
> #1  0xc0521fb1 in db_dump (dummy=-1062244387, dummy2=0, dummy3=-1,
>     dummy4=0xeb36b764 "") at /usr/src/sys/ddb/db_command.c:543
> #2  0xc0521a77 in db_command (cmd_table=<value optimized out>)
>     at /usr/src/sys/ddb/db_command.c:449
> #3  0xc0521790 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502
> #4  0xc0524020 in db_trap (type=<value optimized out>, code=2)
>     at /usr/src/sys/ddb/db_main.c:231
> #5  0xc0af7738 in kdb_trap (type=<value optimized out>,
>     code=<value optimized out>, tf=<value optimized out>)
>     at /usr/src/sys/kern/subr_kdb.c:654
> #6  0xc0fa6d3f in trap (frame=<value optimized out>)
>     at /usr/src/sys/i386/i386/trap.c:720
> #7  0xc0f8fd5c in calltrap () at /usr/src/sys/i386/i386/exception.s:170
> #8  0xc0af6fdd in kdb_enter (why=0xc1111a64 "panic",
>     msg=<value optimized out>) at cpufunc.h:71
> #9  0xc0abe363 in vpanic (fmt=<value optimized out>, ap=<value optimized out>)
>     at /usr/src/sys/kern/kern_shutdown.c:747
> #10 0xc0abe21a in kassert_panic (fmt=<value optimized out>)
>     at /usr/src/sys/kern/kern_shutdown.c:642
> #11 0xc0abb047 in _rm_rlock_debug (rm=0xc156e764,
>     tracker=<value optimized out>) at /usr/src/sys/kern/kern_rmlock.c:640
> #12 0xc0ceb0aa in mac_policy_slock_nosleep (tracker=<value optimized out>)
>     at /usr/src/sys/security/mac/mac_framework.c:198
> #13 0xc0cf22a8 in mac_priv_check (priv=490)
>     at /usr/src/sys/security/mac/mac_priv.c:75
> #14 0xc0aacc15 in priv_check_cred (cred=0xc6ece600, priv=490, flags=0)
>     at /usr/src/sys/kern/kern_priv.c:88
> #15 0xd010cdf0 in socket_check_bind (cred=0xc6ece600,
>     so=<value optimized out>, solabel=0x0, sa=<value optimized out>)
>     at /usr/src/sys/modules/mac_portacl/../../security/mac_portacl/mac_portacl.c:428
> #16 0xc0cf4291 in mac_socket_check_bind (so=0xcf528d40)
>     at /usr/src/sys/security/mac/mac_socket.c:325
> #17 0xc0b41091 in kern_bindat (td=0xc778c930, dirfd=-100,
>     fd=<value optimized out>, sa=0xffff)
>     at /usr/src/sys/kern/uipc_syscalls.c:279
> #18 0xc0b40ea4 in sys_bind (td=0x80, uap=<value optimized out>)
>     at /usr/src/sys/kern/uipc_syscalls.c:297
> #19 0xc0fa7a0e in syscall (frame=<value optimized out>) at subr_syscall.c:134
> #20 0xc0f8fdf1 in Xint0x80_syscall ()
>     at /usr/src/sys/i386/i386/exception.s:270
> #21 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> 
> 
> It easy to reproduce. Just kldload mac_portacl and /etc/rc.d/syslogd restart

This is due to priv_check_cred() call in mac_portacl.c:rules_check().
The call causes recusion into the mac framework from the mac callback.

Robert should have better idea about the proper way to fix the issue.
The trivial attempt might be to enable recursion on the rm lock
protecting the lists.

diff --git a/sys/security/mac/mac_framework.c b/sys/security/mac/mac_framework.c
index 816bb0b..ed0c05a 100644
--- a/sys/security/mac/mac_framework.c
+++ b/sys/security/mac/mac_framework.c
_at__at_ -292,7 +292,8 _at__at_ mac_init(void)
 	mac_labelzone_init();
 
 #ifndef MAC_STATIC
-	rm_init_flags(&mac_policy_rm, "mac_policy_rm", RM_NOWITNESS);
+	rm_init_flags(&mac_policy_rm, "mac_policy_rm", RM_NOWITNESS |
+	    RM_RECURSE);
 	sx_init_flags(&mac_policy_sx, "mac_policy_sx", SX_NOWITNESS);
 #endif
 }