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 DDBA1C0218A for ; Sat, 1 Feb 2025 14:04:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D3776B007B; Sat, 1 Feb 2025 09:04:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 182F26B0082; Sat, 1 Feb 2025 09:04:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04A596B0083; Sat, 1 Feb 2025 09:04:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D2F336B007B for ; Sat, 1 Feb 2025 09:04:08 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5CDB51C7FFB for ; Sat, 1 Feb 2025 14:04:08 +0000 (UTC) X-FDA: 83071544976.11.7264791 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf13.hostedemail.com (Postfix) with ESMTP id 61D2720009 for ; Sat, 1 Feb 2025 14:04:06 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OwHD4CsL; spf=pass (imf13.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738418646; 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=eN1jCbN4WfYnrmUEepmyonmaWx7vzJO9DusAVN5lnzo=; b=GlEcA9YfKoDm0IBTwX3VKSMqkZyadd37XUN0HVoUo9AqQJJgK9gV4VQwu+/X/z2hmag4bK UscwB+SuS/IaKiDSr0Dx6bvsUaMDmR7QBOPLYYPn3cFkMNttOcYaZfMnEZmW/WLrs/NN2G pUNEjTgu1hPNa7zKoAEOUdN+SDVYxHk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738418646; a=rsa-sha256; cv=none; b=NXSUMdU0uEnmv+4AqHiuf8N690uI6nBP3GXFkRgDVWsDqI03PE//nY7KPa/BdtIqackb7H IkCnjnx7P+RH5qqx8vuu144U2MO03w3kOGZzJNxznIx3HqVvHDceumUoO66xAsFudLdifX PK6J8bI3KkoFBmgBZ6NFoW1AN1CtIp0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OwHD4CsL; spf=pass (imf13.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-5d3cf094768so5305765a12.0 for ; Sat, 01 Feb 2025 06:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738418645; x=1739023445; 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=eN1jCbN4WfYnrmUEepmyonmaWx7vzJO9DusAVN5lnzo=; b=OwHD4CsL317lwHKIofCElMYHUMeg4LrdlEfR/ycVzNjcQEkjo6sCx+YEaU55RMxUMA /Ej95mlPZNzh5ZEtC3Lk3mgx2xP11MtM/ZxDIkPqdtn4TdwDJG6e2HIG9gd/S5FWTZq0 S2HbU0n07Q8X1zS9g/3frX8YtUSOIqOZQWLuIiSoBYdYiNRJFXC5tnlCNxqCecp+UPlx 07jtlnmgn6WR0FmfIyKyZN6dB9MjQroGpln7UE8s2o7hZ4lr6XZL2JSrxJ9jLhZ5xxM1 h2gXGPfpc1/UmePPgvk14U/9AUC3fMaUo/FwWpgsO56iP2b9ZXwjJHLNqKvg8E/wxLp4 eTzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738418645; x=1739023445; 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=eN1jCbN4WfYnrmUEepmyonmaWx7vzJO9DusAVN5lnzo=; b=QyKWVvLXEurURwtdjBTV2f4petFgLi0n3yHMFRUqAqG2/VphJIfvsX5x/awXC5cELK N2QgPAg/P5LYL7MuV56qGY9SrO8LVL34jrfbjjknF+2TMl76uhY8c/f6OB8qHZJypUlm 41TKYzaPX6C7YblpdrR6ciLcMNBpUDhHjx2Xz13htYRk+pGZQBXZxBVlrFEwoys0mDUw Q7ngrfrDT/DvvZRCGoLSB3+v9ddJx3PHbVcMSVcYD+UubMH6mNVGGFE8IRAix71jqFfm r+mi7SJa8QCKWIdc+vASc97jfXcKRFRLwYPdEMhzmB/l1R5cVjinrCZ1fW68CB1HanWL kJNg== X-Forwarded-Encrypted: i=1; AJvYcCV0/TNnd0zhefT48KZX1cl6/MbHbVrmumpBUnboJFu0OQf2dlmR1ahDo54NtrwvpMv1ptg6vSAzlw==@kvack.org X-Gm-Message-State: AOJu0YxSA5yrEkp/Xga2QJRVcFGvoJLZmIiCmlPl8r+2SJzpznQLZ1A2 Cf/BpotITnATbONYd9fRrjmxuXur1ubwulsX9csJOaXKYO3b1UZ+bg6grFZRuZ5WRieAGiikPbG 2cn3trtRUMnXJJ3sApju5kreHjQ0= X-Gm-Gg: ASbGnctsIj8kOSkDAw5719xyY+3D5rcYqTICm4ZC4A0gqLUra2jsQtsFkNYqnqVxQpa L9pmCSBDLRLEt2nd7yUsNVbFOxZkMCeiieyT77eOMkP5JvPTLclGNVPWo6/+ypY/xvdNg9R0c X-Google-Smtp-Source: AGHT+IGTgLaUfNVZ5sR+fAzB1ygg3IP1uVFBpiIoBCTVteCkdJ3szhkTxEmPR/yS0XzsgpGW2245XPOSO+RddAAz8Dg= X-Received: by 2002:a05:6402:5106:b0:5d3:ce7f:ac05 with SMTP id 4fb4d7f45d1cf-5dc5effb167mr14682348a12.31.1738418644402; Sat, 01 Feb 2025 06:04:04 -0800 (PST) MIME-Version: 1.0 References: <20250128160743.3142544-1-mjguzik@gmail.com> <87ikpubt4c.fsf@email.froward.int.ebiederm.org> <8734gybmxv.fsf@email.froward.int.ebiederm.org> In-Reply-To: <8734gybmxv.fsf@email.froward.int.ebiederm.org> From: Mateusz Guzik Date: Sat, 1 Feb 2025 15:03:52 +0100 X-Gm-Features: AWEUYZkSowoyLr3pO3SOxKCPculj5K6ekPTJ2Iwr5sHVxZIoBCJwSrDKB3Xph28 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-Rspamd-Queue-Id: 61D2720009 X-Stat-Signature: ny6xf9fwnbegbj6t5kfptcc7z5nzu15m X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1738418646-975239 X-HE-Meta: U2FsdGVkX1+rCZGE9tqpxSZr+qvKi0usGloVibhNenavIb3Jc5eEhKijxRFp8Ef3thFaAyOLMgxSnsPT1c1Hk5zPrEPdaZT4dl1BNvKtzaG9X0OavnquBT3aAReVSVfpOPwCy8EsQOZ1y7zr8zlVZZdHIlV6hEeTN1nzQbzimzNcKLZ2S3x08tWysv/epTcKzXtumQc92zvmn95NxBegnVZ32mJXOBVu/evCzJouve1uL/c084uhizfxs6tMrZfXzfZBNOtSsp5ZQUqynjMv08c5KCKIgtfFp7pHJvUH+Dvt/fDVlCzDzjVzi6nQrM7LERSmCvBloX8Imp0IKV5dx8OvQAM689elOOY4bkKuE8jpLousHuf9mocmoEXTTeqUx7wkGmQQbM04bP7M6+AIK2BNC1lJUhJkEaKCeOGnj/quPwe8slZ/UyR0+BhrrDPGAdCe3O29BIcb5OQlBgqm3iqbwit1CTtq6ZGtp02jpAQWsxtR3c+YJBO5q9uKz0dTL+UpQ3KCm8slOcgtOMX8MEZAVwJ8rdVSD7ubTPwevKNylSmE6bFBMP9kl6rMJ57bQQNRZUADlAzlE3ghoNMWbaW2xnEg+KKL+PI1ZXl3jcdZzXj04SyARXQ1QkBCUuAZn2e3xrnsegkZuo6nR3vINpfV4bAT7pIzQMnQBnZLy51w8kW75BrasaESIgxysXZSzeBS0PfWSAbZX1XilP7a/vF7bQb1zGn+S2kESE5weKC8nhlKvpBY9n2PISBW6qo2X7knCpcrs6CaNk1eFG8XjfYGm9tjIMv7+ujOENTaUoKGk1i08xuM55/nR1N8Bp6kh8XYnNeGnwLsPY3d9SWIhxaISzETLywOftd5jgenHb7C2Kt9zQoI2NlL7fLecXxEpbYylxorM1F6BNoa9hGQTtS2vPeyo26wtB8bx65DKxwp6W8En8CojUcgOlYxZ7/+wTjfJ+vftL6uFdn3ll9 9HoPwS2P vFwNBpyMB0nyZ1Mgph1ivHiAwiYXkYXrRhWZUNJqmTlbn6g5sYb/4lyHxwmYb1i6WRZhcOsC5ROS+1gggaZ8IUat3rgPXCyda2oJBNPaQIkH+PBZDWZvkiCW2uwAsERUnI1+DDy4ijTTR6Oq4IglR8BPI/l0FmTJ3E3WLun5d6BfveGa5AzVBC04OgYv/m/+pkaLwDpMifJiWZJNge2gvpsJc723BWSJAKcFSQNIXJZaL1g0ggcHB2UrmoB7i/6ksN/FEdCQ1nI+U42o+zJw6uAoZz/DsldrOC3WIkXSc8D7AVdwaTNK7d774j39hIeUxlqxEYYXSCc0sEhsAwNFRLVgamvyGNhy+zkuFRRlcAs2G0eqqUBtqWm0Kd77JzG/UTre9W50416mpL0bBwsX0WR78lTZnfDIE+faf1xpxLlCELwq5zcg74Mv/XDIisO1q9vds X-Bogosity: Ham, tests=bogofilter, spamicity=0.073875, 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 Sat, Feb 1, 2025 at 12:09=E2=80=AFAM Eric W. Biederman wrote: > > 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. > I would argue the time window to find the about-to-be-whacked task is not big, but this part is not important enough for me to push for it. So I'm going to drop this bit for now. > >> 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. > Huh, indeed that's how it reads like. That's very poorly stated at best, my= bad. The key was *allocating* a pid happens without the tasklist_lock (but with pidmap_lock) and the part which gets rid of it (detach_pid -> free_pid) operates under both. As you can see the patch keeps detach_pid inside the tasklist_lock-protected area. > >> 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. > There is definitely no rush. I'm going to cook v3 if only just for fun. --=20 Mateusz Guzik