Message ID | 20241017181436.2047508-1-anjali.k.kulkarni@oracle.com (mailing list archive) |
---|---|
Headers | show |
Series | Threads support in proc connector | expand |
On Thu, Oct 17, 2024 at 11:14:33AM -0700, Anjali Kulkarni wrote: > Recently we committed a fix to allow processes to receive notifications for > non-zero exits via the process connector module. Commit is a4c9a56e6a2c. > > However, for threads, when it does a pthread_exit(&exit_status) call, the > kernel is not aware of the exit status with which pthread_exit is called. > It is sent by child thread to the parent process, if it is waiting in > pthread_join(). Hence, for a thread exiting abnormally, kernel cannot > send notifications to any listening processes. > > The exception to this is if the thread is sent a signal which it has not > handled, and dies along with it's process as a result; for eg. SIGSEGV or > SIGKILL. In this case, kernel is aware of the non-zero exit and sends a > notification for it. > > For our use case, we cannot have parent wait in pthread_join, one of the > main reasons for this being that we do not want to track normal > pthread_exit(), which could be a very large number. We only want to be > notified of any abnormal exits. Hence, threads are created with > pthread_attr_t set to PTHREAD_CREATE_DETACHED. > > To fix this problem, we add a new type PROC_CN_MCAST_NOTIFY to proc connector > API, which allows a thread to send it's exit status to kernel either when > it needs to call pthread_exit() with non-zero value to indicate some > error or from signal handler before pthread_exit(). > > We also need to filter packets with non-zero exit notifications futher > based on instances, which can be identified by task names. Hence, added a > comm field to the packet's struct proc_event, in which task->comm is > stored. As it seems that there will be another revision anyway, please run this patch-set through checkpatch with the following arguments. ./scripts/checkpatch.pl --strict --max-line-length=80 And please fix warnings about alignment and line length. But please do so in such a way that doesn't reduce readability, e.g. don't split strings over multiple lines.
> On Oct 18, 2024, at 2:49 AM, Simon Horman <horms@kernel.org> wrote: > > On Thu, Oct 17, 2024 at 11:14:33AM -0700, Anjali Kulkarni wrote: >> Recently we committed a fix to allow processes to receive notifications for >> non-zero exits via the process connector module. Commit is a4c9a56e6a2c. >> >> However, for threads, when it does a pthread_exit(&exit_status) call, the >> kernel is not aware of the exit status with which pthread_exit is called. >> It is sent by child thread to the parent process, if it is waiting in >> pthread_join(). Hence, for a thread exiting abnormally, kernel cannot >> send notifications to any listening processes. >> >> The exception to this is if the thread is sent a signal which it has not >> handled, and dies along with it's process as a result; for eg. SIGSEGV or >> SIGKILL. In this case, kernel is aware of the non-zero exit and sends a >> notification for it. >> >> For our use case, we cannot have parent wait in pthread_join, one of the >> main reasons for this being that we do not want to track normal >> pthread_exit(), which could be a very large number. We only want to be >> notified of any abnormal exits. Hence, threads are created with >> pthread_attr_t set to PTHREAD_CREATE_DETACHED. >> >> To fix this problem, we add a new type PROC_CN_MCAST_NOTIFY to proc connector >> API, which allows a thread to send it's exit status to kernel either when >> it needs to call pthread_exit() with non-zero value to indicate some >> error or from signal handler before pthread_exit(). >> >> We also need to filter packets with non-zero exit notifications futher >> based on instances, which can be identified by task names. Hence, added a >> comm field to the packet's struct proc_event, in which task->comm is >> stored. > > As it seems that there will be another revision anyway, > please run this patch-set through checkpatch with the following arguments. > > ./scripts/checkpatch.pl --strict --max-line-length=80 > > And please fix warnings about alignment and line length. > But please do so in such a way that doesn't reduce readability, > e.g. don't split strings over multiple lines. Ok thanks, will do. Anjali