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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D6C3C0218F for ; Fri, 31 Jan 2025 23:09:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92E306B007B; Fri, 31 Jan 2025 18:09:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DDF96B0082; Fri, 31 Jan 2025 18:09:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77EEF6B0083; Fri, 31 Jan 2025 18:09:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 59BEF6B007B for ; Fri, 31 Jan 2025 18:09:43 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E4C531C83DC for ; Fri, 31 Jan 2025 23:09:42 +0000 (UTC) X-FDA: 83069291004.01.42C5492 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf29.hostedemail.com (Postfix) with ESMTP id 6EF3D120008 for ; Fri, 31 Jan 2025 23:09:40 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738364980; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vXXLQAZkFKC5YTuz6DSwg0pUjfIRf1m2gHVFVjrrisg=; b=nNky0iStnGscw9l+Jk9gNEbHUDziexTPZ5HXMfr7vkW+F2HF+WIaMExjivov4TmltrTh9f CbpUMUYgfFOY9YoqzgKoM5Ne8DoVYmeopgUzYKLIaXOb9PT6WYtmUVPumKvz7m4UWKhWdX N83z5i/QHP7C2shMh3J3k9cRPxxxi44= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738364980; a=rsa-sha256; cv=none; b=Ldmq7fZWcSTqew20ujqaFFzLkjt5KYnAspFn74TtSdKlm6wVE5pw+K1VSnoIxGDFOSJOXR tMStODvEVrdidI58vLAd91/oza19ET5w7ys47EC+/xfL7BAbfKF+5jLub17L5RJZ595/Le YTluR8Cadae8L9IFI2Sw4nbucJBNvNw= Received: from in02.mta.xmission.com ([166.70.13.52]:44162) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1te08o-00B30L-ME; Fri, 31 Jan 2025 16:09:38 -0700 Received: from ip72-198-198-28.om.om.cox.net ([72.198.198.28]:46716 helo=email.froward.int.ebiederm.org.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 1te08n-009VU4-LX; Fri, 31 Jan 2025 16:09:38 -0700 From: "Eric W. Biederman" To: Mateusz Guzik Cc: brauner@kernel.org, oleg@redhat.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20250128160743.3142544-1-mjguzik@gmail.com> <87ikpubt4c.fsf@email.froward.int.ebiederm.org> Date: Fri, 31 Jan 2025 17:09:16 -0600 In-Reply-To: (Mateusz Guzik's message of "Fri, 31 Jan 2025 23:31:01 +0100") Message-ID: <8734gybmxv.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1te08n-009VU4-LX;;;mid=<8734gybmxv.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=72.198.198.28;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX19kdD9GOaw2BtZ9qBaamkzRB6szcjh2wn0= Subject: Re: [PATCH v2] exit: perform randomness and pid work without tasklist_lock X-SA-Exim-Connect-IP: 166.70.13.52 X-SA-Exim-Rcpt-To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, oleg@redhat.com, brauner@kernel.org, mjguzik@gmail.com X-SA-Exim-Mail-From: ebiederm@xmission.com X-SA-Exim-Scanned: No (on out01.mta.xmission.com); SAEximRunCond expanded to false X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6EF3D120008 X-Stat-Signature: 16kdxkowfyebpidnbyoaza7r4sftkmyo X-Rspam-User: X-HE-Tag: 1738364980-76461 X-HE-Meta: U2FsdGVkX19MSimkFPkslcR8G6vfT/K2Zo6EBU29kNzHFOaTlEECojWGNlU1uLoE8TNxatGfvEN2WET/gbpvH8jMEbuIKicP/f8lLXBOTZqCgRN++1q7DKLTbIrLamgU0zVH4N1J7P0F+jGepSMwCtFEb1izmoPjK1a0lDTn0sjfp5dMxwpfJCJfPvU3zPJ/gEqj65PocLt3bL8NwCtFXm2a10WMZoq/sCsONpRu5ZCKZvVgSQajr6mhC22tGfszBlCtgBXgykuRJRvtXWliOsC7wp4K/RSmL2QSLEy+ycHqoj2ma9NgvCWtxzDQqdiR1zCO6RKbBpcMGX8RmXC/r6cfzs9at4J86+zYkQRoN4kRwlYaGYMsSclxb47fl7OkKzOWQWirPq6gamzSE2JuugsWiju379dgpIWDMQCyN17cYvDUJTue8NcclbbQ8P0u6LdOeuRdHjpzFbPRcs27qVaWkF/eGnjQnnIX0obcie47Rl4VXxo33di+EbiG1EvQf9SC+Fee7ah2HWzD2xqHeB9ppnqtjhP+SFe3/Xf37s7jPCMtiC6vF3R50NJ+TuYWatU/CtHOOLRw5NnuL0z9RpQmg6pGUhWqX/mXiPEOLCkhgYoj3XRHAFCqnAZkJUxnd4gC8wsiQx5l/2r+9KbCm7WkuqUR4Ml5Rd4FmtdjRGG6LuVI/AUEBCgRdyRogGTnLdOun9K8Uv/Nf/FLMGWOqZKW//n2RtZXZ100CgNyZ5w6grWMTeeiqCOpvyyXoowGpsUJYBDKCFBwolCMUN7TibiMTmtB4b3/yUjhmQ0Lhfvvfrc6LPYhVpEsw6GfFLTS9xtzQGNiRGi3hZ4B8hAzHh8Jo4GVUlreHQzE504FNw6eVMBuNxwCHiItNgki1mYDiXVkJLAaze4/W4E5eogMFwWx1/aHgyz3hU75dpRIdfn0ZYHwpONkbRnmpaoNiB6KH7MRlo7lirYeAgZ92ni iiMJtSLo D6ett2h9GHqlc/5CGM6sYJQC8SqRA4S1xHm/pBbl1pbYNdEV07A1DZ354ojtNpKVzgAlJtEF9cL719ZPeKxOpuLQyu98ashNkQnlQVBfLyprmu94QoIuCDZhrqNRvRQXvKfAIXMduqVN8OjBJn9eFBnS2dtZu9P7CfLIxqYXkUKTDiI28YrYr9pWU/JOu7QQQwQhm X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Mateusz Guzik writes: > On Fri, Jan 31, 2025 at 9:56=E2=80=AFPM Eric W. Biederman wrote: >> Moving proc_flush_pid inside of tasklist_lock is a bad idea. > > The patch does not make such a change though. > > The call is still performed without the lock, but it also dodges the > additional refcount dance (and notably eliminates an atomic from an > area protected by tasklist_lock). My mistake I saw you had moved it up, but I had missed just how far. It is still a bad idea to move it early, as that has caused problems with lingering proc entries for reaped task clogging up the dcache. >> It is wrong that attach_pid/detach_pid can be performed without the >> tasklist_lock. There are reasonable guarantees provided by the posix >> standard that the set of processes sent a signal is the set of >> processes at a point in time. The tasklist_lock is how we provide >> those guarantees currently. >> > > I don't see anything calling these without the lock and neither my > patch nor a follow up about pids suggest anything of the sort. No. You simply said fork called attach_pid without the lock and your description implied it was safe to call attach_pid/detach_pid without the lock. >> There are two more layers to pids. The pid number allocation of >> alloc_pid/free_pid, and the struct pid layer maintained by get_pid, >> put_pid. Those two layers don't need the tasklist_lock. >> >> >> It is safe to move free_pid out of tasklist_lock. I am not certain >> how sane it is. >> > > Where is the sanity problem here? AFAICS this just delays some wakeups > in the worst case. At the end of the day it might be a sensible way to go. I just haven't found the arguments to convince my gut of that yet. It is important for me at least to convince my gut because it usually notices problems before the rest of me does. Eric