Only send SIGKILL on last close.
Lock proctree around pdopenpid() working on the process.
Restructure kern_pdopenpid() to avoid the mess of specific error return pathes.

Added comment explaining that UID and GID are chosen to be unused.

That looks correct too.

You mean the TIOCSTI definition was hidden?

Sorry, yes. The ioctl definition.

In D57163#1311399, @markj wrote:

I cannot apply the patch, it fails in pdfork.2. (I already applied the pdopenpid() patch.) Could you please rebase? Or, if your branch is already public, could you please include a pointer to it in the review description so that it's easier for me to fetch? That makes it easier for me to e.g., write syzkaller descriptions for new syscalls.

I cannot apply the patch, it fails in pdfork.2. (I already applied the pdopenpid() patch.) Could you please rebase? Or, if your branch is already public, could you please include a pointer to it in the review description so that it's easier for me to fetch? That makes it easier for me to e.g., write syzkaller descriptions for new syscalls.

rebase

rf

rf

In D50614#1311340, @emaste wrote:

In my tree I hid the sysctl to find consumers and confirm that the system works without it. The consumers are:

• Rework validition to avoid multiplication.
• Fall back to the extended signature table if the processor flags don't match.

@jfree ping

In my tree I hid the sysctl to find consumers and confirm that the system works without it. The consumers are:

• clang sanitizers
• tcsh
• mail
• this test

I don't really understand--if we were to remove TIOCSTI, wouldn't that be done by removing the runtime implementation, rather than hiding the TIOCSTI symbol like this?

In D57209#1310974, @jrm wrote:

Thanks both. Nice catch to fix the inverted condition. If I understand correctly, before this fix, we would never have detected an extended signature, and thus never applied microcode for processors only listed in the extended signature.

I don't really see the point. I'd just keep the option, having it silently do nothing, and remove the documentation.

ope, thanks for catching that. I also forgot to update the acpi(4) manpage and a couple other comments in other files but I can commit a fix for those separately

In D56835#1311274, @kib wrote:

In D56835#1311164, @imp wrote:

I'd like to echo the user requirement. I have not current need for it at $WORK, but can see a need in the future. Having the ability for users to tie into the startup, running as themselves, much like we allow users to add jobs to cron, at, etc would be a useful, but not gating, feature.

There is a @reboot keyword support in our crontab, working for user's crontab.

Update usage.