OS-3794

You can, it seems, induce a panic from an LX zone by causing the LX-branded init process to die on a signal. The panic stack looks like:

fffffffffbc7bca0 kmdb_enter+0xb()
fffffffffbc7bcd0 debug_enter+0x5d(fffffffffb9324d0)
fffffffffbc7bdb0 panicsys+0x5b9(fffffffffb92b91f, ffffff00056eec20,
fffffffffbc7bdc0, 1)
ffffff00056eec10 vpanic+0x15c()
ffffff00056eec80 param_preset()
ffffff00056eeca0 mutex_panic+0x58(fffffffffb92b93c, ffffff0147a32dc0)
ffffff00056eed10 mutex_vector_enter+0x2b7(ffffff0147a32dc0)
ffffff00056eed50 killall+0x7c(1, 0)
ffffff00056eedb0 zone_kadmin+0xf3(1, 0, 0, ffffff0150e3d020)
ffffff00056eedf0 lx_brand`lx_proc_exit+0xc5(ffffff0150e67048, ffffff014a409cc0)
ffffff00056eee20 brand_clearbrand+0x3e(ffffff0150e67048, 0)
ffffff00056eeec0 proc_exit+0x11a(1, b)
ffffff00056eeee0 exit+0x15(1, b)
ffffff00056eef00 rexit+0x18(b)
ffffff00056eef10 sys_syscall+0x17a()

This is induced by lx_proc_exit calling into zone_kadmin while holding the current process lock. The current process is, apparently, not yet exited enough to be ignored by the subsequent killall call and it tries to re-take our lock.

Trivially altering our routine to drop p_lock while calling zone_kadmin is unhelpful; we end up re-entering exit and fail to remove the brand thread context operations for a second time.

If the reboot behaviour is removed altogether, though it does not do what we want from a Linux perspective (i.e. init death causes a kernel panic!!!) it also does not panic the machine.

Former user commented on 2015-02-12T20:32:51.000-0500: