Fix panic with Linux apps and RACCT/RCTL.

[trasz]

Summary

The patch below fixes a panic triggered by threaded Linux applications
when running with RACCT/RCTL enabled. The crash, as reported, looked
like this:

panic: racct_sub: freeing 1 of resource 11, which is more than allocated 0 for
wcgrid_fahv_vina_pr (pid 1140)

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: racct_sub: freeing 1 of resource 11, which is more than allocated 0 for
wcgrid_fahv_vina_pr (pid 1140)
cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe2eb3859920
vpanic() at vpanic+0x189/frame 0xfffffe2eb38599a0
kassert_panic() at kassert_panic+0x132/frame 0xfffffe2eb3859a10
racct_sub() at racct_sub+0x13e/frame 0xfffffe2eb3859a50
exit1() at exit1+0xd4/frame 0xfffffe2eb3859ad0
linux_exit_group() at linux_exit_group+0xd/frame 0xfffffe2eb3859ae0
ia32_syscall() at ia32_syscall+0x28b/frame 0xfffffe2eb3859bf0
Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfffffe2eb3859bf0

• syscall (252, Linux ELF32, linux_exit_group), rip = 0x817a9d7, rsp =

0xffffca3c, rbp = 0xffffca58 ---

[emaste]

sys/compat/linux/linux_fork.c

301 ↗

(On Diff #8165)

I'm curious why you don't do the racct_sub here, in this if. As a hint to someone who may modify this file in the future, adding another error return case?

[trasz]

sys/compat/linux/linux_fork.c

301 ↗

(On Diff #8165)

Exactly. And also to avoid diverging from a very similar code in sys/kern/kern_thr.c.

[ngie]

It seems like the relevant calls in kern_thr.c should at least be refactored into 2 helper functions and called from here and from there, and potentially applied to the cloudabi stuff ed's been working on.

[ngie]

As for right now though, this looks like a good solution to unbreak Larry though (it matches what's done in kern_thr.c:thread_create). I would commit it to unbreak LINUX + RACCT, then work on a proper solution.

I'd get signoff from someone else who did linux compat though, like dchagin.

[ed]

In D3470#72335, @ngie wrote:

[...] and potentially applied to the cloudabi stuff ed's been working on.

On the CloudABI side it's all good. CloudABI's thread creation system call just calls into thread_create() to do all of its hard work. :-)

[ler]

This comment was removed by ler.