Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp719200pxf; Wed, 10 Mar 2021 16:18:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJz/Mmot2NlM6IF41Dm5BUAkHLfT1G8VtxW2BOSi8Tw/YRVvsckPbu6/0PrmHE9XlrvDv0Fx X-Received: by 2002:a17:906:b316:: with SMTP id n22mr425733ejz.249.1615421904339; Wed, 10 Mar 2021 16:18:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615421904; cv=none; d=google.com; s=arc-20160816; b=nvK5hpPNbOErZfpqUkHvg7SdgAKpRFBDwpSBYminEGvu/ADYjn4sIRvSE+HPg7CeW2 mmRkyBXZG5ytYJsHVWJhqV1LaVREXYKMIBqOJiGx/9A1a8zKduwlPj/3yFXHaXL1BSRz FKRWGNdXT1Rvyqv/OhKxSkOsHNLYPNjhdtv4dYFjJgfPlIkEd+hMg75Ycsdb22FlzA68 k4a+gA3pB+lhzpwXBeWTGqaMOdwWF5cs9ABt8NvCd/lyRuqMPYd8e5nQ1RnLXcXAVeBE H5BoxZj6d5J3vM+vfAPOekKKDlaHa/S7x6qW/uBmoo0tb+BtUtNwp4OMggtUMt3LpxKC VCeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:date:message-id:organization:from :references:cc:to:subject; bh=WB+pNtYGQInpcL+kaMfD9AF2j++cMTUp5zeYZsW4ePo=; b=dzJZ8jM/SSCgD1kX8qxiQRcMJFJAsQYX6j46ot3fWnEhCEh/HaYMLYDw91XI56aC3E j9WLWs/nlvWLBpWsjfzY9Y+IqhtxISrLj0eIqSPHQv4B2YFLNhYX39Q8yZzXXi3c4pLL A8kvsYazXAk01P3NaNqcnk1wBGezKhOhE70zzQFkXl2A13NEyfC7sUSWE+6PsLX9H48l OAR5B/0oI9bTBkB67PV08bRFdBRAzu1e/3jy6pAp2TVaHqQCvSw0rsqZe9+HJfFO+dbq +d4YurEwn7DTZCRp8aG2CUuvnr9flh2y8FQY00+NcQjiEv6ukCtRuASE+5Qp3IN+4c7d xB6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r12si658827ejz.5.2021.03.10.16.18.02; Wed, 10 Mar 2021 16:18:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229570AbhCKAPB (ORCPT + 99 others); Wed, 10 Mar 2021 19:15:01 -0500 Received: from mx1.riseup.net ([198.252.153.129]:45844 "EHLO mx1.riseup.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbhCKAOt (ORCPT ); Wed, 10 Mar 2021 19:14:49 -0500 Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4DwqFf6MpczDr7f; Wed, 10 Mar 2021 16:14:46 -0800 (PST) X-Riseup-User-ID: 43F2163302C5606AA3D2042CD277FE5A858B1735C3F7A0046289050BAA082231 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4DwqFd4LpSz5vNY; Wed, 10 Mar 2021 16:14:45 -0800 (PST) Subject: Re: [PATCH v3] do_wait: make PIDTYPE_PID case O(1) instead of O(n) To: "Eric W. Biederman" Cc: Andrew Morton , Oleg Nesterov , Christian Brauner , linux-kernel@vger.kernel.org References: <20210309203919.15920-1-jnewsome@torproject.org> From: Jim Newsome Organization: The Tor Project Message-ID: <4d9006b4-b65a-6ce0-b367-971f29de1f21@torproject.org> Date: Wed, 10 Mar 2021 18:14:44 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) Thanks! -Jim