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 5226BC0218F for ; Fri, 31 Jan 2025 22:31:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 97F956B007B; Fri, 31 Jan 2025 17:31:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 92FD06B0082; Fri, 31 Jan 2025 17:31:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F7D86B0083; Fri, 31 Jan 2025 17:31:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5891D6B007B for ; Fri, 31 Jan 2025 17:31:17 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B421B81168 for ; Fri, 31 Jan 2025 22:31:16 +0000 (UTC) X-FDA: 83069194152.17.13C5C50 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf29.hostedemail.com (Postfix) with ESMTP id CFBBF12000D for ; Fri, 31 Jan 2025 22:31:14 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Go6nMBiD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738362674; a=rsa-sha256; cv=none; b=rIoH7Z4k5UachMNW1iW0FFTdOSsptOQvNUACcwohN15b5esv0JCZ62Ag+IrnKHwqUBUJGM SmComr1DuCNfWjK41i90EbiKw6fjUei5mNGyxwcmTHgULWEwU7KONFTTeek7ZaXxT3UQu6 DqglqgpxZYeGq48JnfbCbMGeg6RLb+0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Go6nMBiD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738362674; 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:dkim-signature; bh=GKsXBpMAtVNtSV6mG/j/GoHK9YgSZd073Jd3YtYAnLI=; b=BlrEtjTyHXvoBObSJw28C+2OZtL2N7f9WTN/KyUyeG5rxXFdE0yVA3z+n/qNXcYirxd8JB LmcFBZK9i8fq97jJuhn5ZFaQTBbQ8vudZXf3Wiaqu3lQzDRxo0WpLYSKAsKYoM2pqGhYLe 3k14n7fvzhHvQCbT4jCjLCxAROrOD2w= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5d3d0205bd5so3727127a12.3 for ; Fri, 31 Jan 2025 14:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738362673; x=1738967473; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GKsXBpMAtVNtSV6mG/j/GoHK9YgSZd073Jd3YtYAnLI=; b=Go6nMBiDi6bkbmajP6fpPXTRuk3jVFCxOtLpCiVVgP/GHbxTQTf1kX4bzBH1e8055a WzdVXMpyTJCzTQi6EXg571PE+ucLG/vFoJBXEg6ijnMSsgSbWdFHpmDynfLZkfTSccUn Rcc/7gSoeaxQqErPftLHLASZV2ch2UutAMQ6J4t/Qwi83i3MZ9J8nyAgEbnd1iKbDJ89 VN0KnfbltYYF2F3Fa8g68docRjuk/dgql5ZW12iobv7Ua/t3yBQyU3yGwI17eyUzhsfG v7iyBeg85zCnrENi+Uf2Ey0FaE6Awf3Bw1BpqgN0k7V0HxEB6LHlknktp5EBWlNeBrVZ qDpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738362673; x=1738967473; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GKsXBpMAtVNtSV6mG/j/GoHK9YgSZd073Jd3YtYAnLI=; b=SrSng9mnYvuKhojrBw9J37cprvUt+dRAAG7rC0crLq4xljUtyUOk7W8kspLu3bY+dY IXTyzTDo1m/iUlPBtjuRdkmlPH8JE+2L2pk3B1ZbV/5i0WOBhp8WpH0aNr/OtLtPKMXa v8GKGnbO62DVKKeai5aG57fPHSL3JZOC1jBOLtLDBmgRKPqI21KnCUJ4uaOg9NK2eTrl fJt1wSs8RdMW4aLDsFAdKlMNLKiUXPysFVNlgpjBn8Tvx3ko/eGMAbgVD2rQjop50Rdu uel7T5O+NM+xe966kbi6cTapVcTMUfU3iLZ3LWvVyTm/6AnU03IPKHAHPY+UMe70Cid5 Hq2Q== X-Forwarded-Encrypted: i=1; AJvYcCUk7i/+29bpvlr4A77ZHllomT0jBxfdulTSMCb6Nb4rTzyZTvz41+fhL+l8iIVQrcY+gKbdp+Fcpg==@kvack.org X-Gm-Message-State: AOJu0YxGALBi8hXfklxSp1qTTfQMrDc3WH0TvWWPRLLVb5+nSpcqVNBA cLzm5p2+4e95sGj/kJ0hkAflIbg/N/ac0oXavnSJMdYcwH1nK2DZZId8o4SQq3s+V4YgBRIKkJq 2SK8CuVWY9/KoM4+zaNKE0oj+AP0= X-Gm-Gg: ASbGncusYu9CGnGuLlL/kHg47pJYfbktxhC4pTfEEXCIgDLXel1G0q0vecfaK9iFCo3 PxZCNkalcgDXMpD50AxCJ0LWodNM8LlQkG28+TiFnkoWEe9MTFq2Iwa1KLIEG7WJ4Qipbo5uC X-Google-Smtp-Source: AGHT+IEQ5yZBthZMm8y1uTFR/umSZ/26VKcWRXpeVX+Hs4H4/A+qmkdVBwnHcFkRtHihobc7gxlblsFWrSJBAPn2Wyw= X-Received: by 2002:a05:6402:1e93:b0:5da:d76:7b2e with SMTP id 4fb4d7f45d1cf-5dc5e6d858bmr14698171a12.0.1738362673028; Fri, 31 Jan 2025 14:31:13 -0800 (PST) MIME-Version: 1.0 References: <20250128160743.3142544-1-mjguzik@gmail.com> <87ikpubt4c.fsf@email.froward.int.ebiederm.org> In-Reply-To: <87ikpubt4c.fsf@email.froward.int.ebiederm.org> From: Mateusz Guzik Date: Fri, 31 Jan 2025 23:31:01 +0100 X-Gm-Features: AWEUYZkoLfYUPWZOALHy2ZhQOXsP1g4Y_I9LMR1orwBiiQ3WDvQ_4Et8wN_qflo Message-ID: Subject: Re: [PATCH v2] exit: perform randomness and pid work without tasklist_lock To: "Eric W. Biederman" Cc: brauner@kernel.org, oleg@redhat.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: CFBBF12000D X-Rspamd-Server: rspam10 X-Stat-Signature: zkc5nx5b5ny3xwudisi1y186qfm9677t X-HE-Tag: 1738362674-515960 X-HE-Meta: U2FsdGVkX19AYmLEaQ+U+7wHQEAfx8ezXMJA9aEw31ZvoYMJKR3lZMx79IRnyfaKhrIykZyg5hjPgPQEPYrwV72QBaYpXFt1ZTJMkr+E5lcBUggjXgBoiMnGLLp77BuUZGUnOpT49ZTXAHeXl7McUflP2f7cMc06LL8PYhzEz8awS3jvRTYcK0pLwr3/bn80R2LfAJIhA9lcz9LlrJ14Fo+RIkSyl2MbAJqDmEBOt6ZSoYmOqmZz1FYfk1g5WWFpxCq/Cg0DOIfmUVrMOjrjsobYFpKjgTXqlVk24bnRdcEUc30nnDsW2427MB2SWp4MUog5Vf5aQ0Cn2qJyIuapQfhDHztkjYoXGNM42FEi4ufO0ESSJA7cuFAPkk5vqPCnBQCMPF7zCBxTWEg3tsepUVf2ZsOxuE/3ab+IzkOPhez+dbhGhTt01Z6uO66drUKoywL8pztUlHPLsLQJ3cYwCRbYg6DFcu2n9LMTEiyEm63NhTFE8RmPPTruMPvHkKjUTK5wlEQyDYf3IqEmguYx7gwgKmENzlT5FHbJe4HWHvxLCodVXSUt4rM1rUW20AAy2/yucXgcptmpQSVbO9IAlD9LvIA22oEa1Yt7wbjUn+xqMfLsEPLY7Pbq90xhHWw/Cs1GIh4ZerTyibowuOoNgkZX3iUVnLfjufXu0gpgnXw0LhIR8ZWtKHHxUPB/458DvjXB0Qo3tHbxN1J9dSgkhb5vyRgQgYe9EqAtS/jxVg16OlFtIXdqzfhDH4wg/GzRsS/Nh1Lg61zBzRo3EVgJvfazZtx4TdDxOEr7i9vh0NRWwuHxpire/JYLjb3VmJj5dRz0zKUd0PytR42h7lrSmGQYw47oW+7YFS/nebAph4AJwmZZY8Z6OMTPJJgr+Yz6yMaEhdi9K1hn7u8ofjGy/R4Cnt2Of+5j2EsaMWg/hR5//eTDpw6RbvzKyvzTh1wIq0//yK9N5Jfyxia2Xqm Bsypz//R Eh00t1aerH9jZQwTX6aIEdIffaevC2BafA4Wn/r+/tILvrjcbioabgpRLmxrMA/XjSrcYdle87f4p5g1dND7URel+POQTPj3ac9nI88xWzwKHEiojnfxxzjDvjHUPQGyhhj2ty/cE2zCyxRiY1vjFBJZm2dJlVVCc/u1MjmrKfeR2GeT/jCQoAWroIR+mp07tyjZyf5m5XAfLRtTZv0CYZauMzw+eesa4MAZkrJeU4UTJy7UcL8XNcsPWm15/sgYBP9GJUNZ1oEXXF1YioZ54TdhVhotVDYkmCeRBCpKFsHKg7/5yoOjp9KCnHGKTsDpG72YZIfgpeaisEZGjTY26s6FcFSXFWa3QoFYOvIyjYTBdHIl0k+yC8WVJJ1bwtFUGU7+8USlqFO0MDWHy/y7Q1fnirK3gePtJ0z/WhJ4cra0qEYMh07vYqiOpgOICldWx+40W X-Bogosity: Ham, tests=bogofilter, spamicity=0.087933, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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). > > 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. > 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. Regardless, looks like I have enough to send a v2 for further commentary. --=20 Mateusz Guzik