# Re: \[PATCH 1/1\] mm: introduce process\_reap system call - List: linux-api - 5 messages, 3 authors - Page: https://ratatoskr.run/linux-api/2021/07/1436125/t ## Re: \[PATCH 1/1\] mm: introduce process\_reap system call - From: Florian Weimer \ - Date: 2021-07-08 05:41:23 - Message: https://ratatoskr.run/linux-api/2021/07/1436125.md ```text * Suren Baghdasaryan: > On Wed, Jul 7, 2021 at 2:47 AM Florian Weimer [ref] wrote: >> >> * Suren Baghdasaryan: >> >> > The API is as follows, >> > >> > int process_reap(int pidfd, unsigned int flags); >> > >> > DESCRIPTION >> > The process_reap() system call is used to free the memory of a >> > dying process. >> > >> > The pidfd selects the process referred to by the PID file >> > descriptor. >> > (See pidofd_open(2) for further information) >> > >> > The flags argument is reserved for future use; currently, this >> > argument must be specified as 0. >> > >> > RETURN VALUE >> > On success, process_reap() returns 0. On error, -1 is returned >> > and errno is set to indicate the error. >> >> I think the manual page should mention what it means for a process to be >> “dying”, and how to move a process to this state. > > Thanks for the suggestion, Florian! Would replacing "dying process" > with "process which was sent a SIGKILL signal" be sufficient? That explains very clearly the requirement, but it raises the question why this isn't an si_code flag for rt_sigqueueinfo, reusing the existing system call. Thanks, Florian ``` ## Re: \[PATCH 1/1\] mm: introduce process\_reap system call - From: Suren Baghdasaryan \ - Date: 2021-07-08 06:06:12 - Message: https://ratatoskr.run/linux-api/2021/07/1436129.md ```text On Wed, Jul 7, 2021 at 10:41 PM Florian Weimer [ref] wrote: > > * Suren Baghdasaryan: > > > On Wed, Jul 7, 2021 at 2:47 AM Florian Weimer [ref] wrote: > >> > >> * Suren Baghdasaryan: > >> > >> > The API is as follows, > >> > > >> > int process_reap(int pidfd, unsigned int flags); > >> > > >> > DESCRIPTION > >> > The process_reap() system call is used to free the memory of a > >> > dying process. > >> > > >> > The pidfd selects the process referred to by the PID file > >> > descriptor. > >> > (See pidofd_open(2) for further information) > >> > > >> > The flags argument is reserved for future use; currently, this > >> > argument must be specified as 0. > >> > > >> > RETURN VALUE > >> > On success, process_reap() returns 0. On error, -1 is returned > >> > and errno is set to indicate the error. > >> > >> I think the manual page should mention what it means for a process to be > >> “dying”, and how to move a process to this state. > > > > Thanks for the suggestion, Florian! Would replacing "dying process" > > with "process which was sent a SIGKILL signal" be sufficient? > > That explains very clearly the requirement, but it raises the question > why this isn't an si_code flag for rt_sigqueueinfo, reusing the existing > system call. I think you are suggesting to use sigqueue() to deliver the signal and perform the reaping when a special value accompanies it. This would be somewhat similar to my early suggestion to use a flag in pidfd_send_signal() (see: https://lore.kernel.org/patchwork/patch/1060407) to implement memory reaping which has another advantage of operation on PIDFDs instead of PIDs which can be recycled. kill()/pidfd_send_signal()/sigqueue() are supposed to deliver the signal and return without blocking. Changing that behavior was considered unacceptable in these discussions. On the other hand using some kthread to do the reaping asynchronously has its disadvantages: userspace can't control the priority and cpu affinity of the thread doing the reaping and this work is not charged towards the caller. In the end a separate blocking syscall was deemed appropriate for this operation. More details can be found in the links I posted in the description of the patch. > > Thanks, > Florian > ``` ## Re: \[PATCH 1/1\] mm: introduce process\_reap system call - From: Jan Engelhardt \ - Date: 2021-07-12 13:00:22 - Message: https://ratatoskr.run/linux-api/2021/07/1441934.md ```text On Thursday 2021-07-08 08:05, Suren Baghdasaryan wrote: >> >> That explains very clearly the requirement, but it raises the question >> why this isn't an si_code flag for rt_sigqueueinfo, reusing the existing >> system call. > >I think you are suggesting to use sigqueue() to deliver the signal and >perform the reaping when a special value accompanies it. This would be >somewhat similar to my early suggestion to use a flag in >pidfd_send_signal() (see: >https://lore.kernel.org/patchwork/patch/1060407) to implement memory >reaping which has another advantage of operation on PIDFDs instead of >PIDs which can be recycled. >kill()/pidfd_send_signal()/sigqueue() are supposed to deliver the >signal and return without blocking. Changing that behavior was >considered unacceptable in these discussions. The way I understood the request is that a userspace program (or perhaps two, if so desired) should issue _two_ calls, one to deliver the signal, one to perform the reap portion: uinfo.si_code = SI_QUEUE; sigqueue(pid, SIGKILL, &uinfo); uinfo.si_code = SI_REAP; sigqueue(pid, SIGKILL, &uinfo); ``` ## Re: \[PATCH 1/1\] mm: introduce process\_reap system call - From: Suren Baghdasaryan \ - Date: 2021-07-12 18:39:25 - Message: https://ratatoskr.run/linux-api/2021/07/1442223.md ```text On Mon, Jul 12, 2021 at 5:51 AM Jan Engelhardt [ref] wrote: > > > On Thursday 2021-07-08 08:05, Suren Baghdasaryan wrote: > >> > >> That explains very clearly the requirement, but it raises the question > >> why this isn't an si_code flag for rt_sigqueueinfo, reusing the existing > >> system call. > > > >I think you are suggesting to use sigqueue() to deliver the signal and > >perform the reaping when a special value accompanies it. This would be > >somewhat similar to my early suggestion to use a flag in > >pidfd_send_signal() (see: > >https://lore.kernel.org/patchwork/patch/1060407) to implement memory > >reaping which has another advantage of operation on PIDFDs instead of > >PIDs which can be recycled. > >kill()/pidfd_send_signal()/sigqueue() are supposed to deliver the > >signal and return without blocking. Changing that behavior was > >considered unacceptable in these discussions. > > The way I understood the request is that a userspace program (or perhaps two, > if so desired) should issue _two_ calls, one to deliver the signal, > one to perform the reap portion: > > uinfo.si_code = SI_QUEUE; > sigqueue(pid, SIGKILL, &uinfo); > uinfo.si_code = SI_REAP; > sigqueue(pid, SIGKILL, &uinfo); This approach would still lead to the same discussion: by design, sigqueue/kill/pidfd_send_signal deliver the signal but do not wait for the signal to be processed by the recipient. Changing that would be a behavior change. Therefore we would have to follow this pattern and implement memory reaping in an asynchronous manner using a kthread/workqueue and it won't be done in the context of the calling process. This is undesirable because we lose the ability to control priority and cpu affinity for this operation and work won't be charged to the caller. That's why the proposed syscall performs memory reaping in the caller's context and blocks until the operation is done. In this proposal, your sequence looks like this: pidfd_send_signal(pidfd, SIGKILL, NULL, 0); process_reap(pidfd, 0); except we decided to rename process_reap() to process_mrelease() in the next revision. ``` ## Re: \[PATCH 1/1\] mm: introduce process\_reap system call - From: Jan Engelhardt \ - Date: 2021-07-12 19:16:36 - Message: https://ratatoskr.run/linux-api/2021/07/1442259.md ```text On Monday 2021-07-12 20:39, Suren Baghdasaryan wrote: >> >> The way I understood the request is that a userspace program (or perhaps two, >> if so desired) should issue _two_ calls, one to deliver the signal, >> one to perform the reap portion: >> >> uinfo.si_code = SI_QUEUE; >> sigqueue(pid, SIGKILL, &uinfo); >> uinfo.si_code = SI_REAP; >> sigqueue(pid, SIGKILL, &uinfo); > >This approach would still lead to the same discussion: by design, >sigqueue/kill/pidfd_send_signal deliver the signal but do not wait for >the signal to be processed by the recipient. Oh, so the only reason not to do that is because there is some POSIX specification that says the sigqueue API should be non-waiting for all possible parameter values (with an implied "present and future values!"), not because there's some hurdle to actually add a wait inside within rt_sigqueueinfo if the REAP flag is set. Gotcha. ```