From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A73BCC433E6 for ; Thu, 11 Mar 2021 16:31:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 59D4464F9F for ; Thu, 11 Mar 2021 16:31:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229599AbhCKQai (ORCPT ); Thu, 11 Mar 2021 11:30:38 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:50230 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229608AbhCKQaH (ORCPT ); Thu, 11 Mar 2021 11:30:07 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lKOCK-006Yp6-ET; Thu, 11 Mar 2021 09:30:05 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lKOCJ-002zwx-DR; Thu, 11 Mar 2021 09:30:04 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Jim Newsome Cc: Andrew Morton , Oleg Nesterov , Christian Brauner , linux-kernel@vger.kernel.org References: <20210309203919.15920-1-jnewsome@torproject.org> <4d9006b4-b65a-6ce0-b367-971f29de1f21@torproject.org> Date: Thu, 11 Mar 2021 10:30:08 -0600 In-Reply-To: <4d9006b4-b65a-6ce0-b367-971f29de1f21@torproject.org> (Jim Newsome's message of "Wed, 10 Mar 2021 18:14:44 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lKOCJ-002zwx-DR;;;mid=;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+m8dO/ge78RntGs8rj8stSQIb2dmMTiio= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v3] do_wait: make PIDTYPE_PID case O(1) instead of O(n) X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jim Newsome writes: > On 3/10/21 16:40, Eric W. Biederman wrote: >>> +// Optimization for waiting on PIDTYPE_PID. No need to iterate > through child >>> +// and tracee lists to find the target task. >> >> Minor nit: C++ style comments look very out of place in this file >> which uses old school C /* */ comment delimiters for >> all of it's block comments. > > Will do > >>> +static int do_wait_pid(struct wait_opts *wo) >>> +{ >>> + struct task_struct *target = pid_task(wo->wo_pid, PIDTYPE_PID); >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> This is subtle change in behavior. >> >> Today on the task->children list we only place thread group leaders. > > Shouldn't we allow waiting on clone children if __WALL or __WCLONE is set? > > This is already checked later in `eligible_child`, called from > `wait_consider_task`, so I *think* the current form should already do > the right thing. Now I'm confused though how the general path (through > `do_wait_thread`) works if clone children aren't on the task->children > list...? > > (In any case it seems this will need another version with at least an > explanatory comment here) What I am worried about are not clone children. AKA ordinary children that have a different exit signal but CLONE_THREAD children that are never put on the children list so are naturally excluded from today's do_wait (except in the case of ptrace). These are also known as threads. Maybe I am missing it but I don't see anything in wait_consider_task or in the way that you are calling it that would exclude CLONE_THREAD children for the non-ptrace case. Eric