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=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 B7C9AC07E96 for ; Thu, 8 Jul 2021 06:06:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 54EB561CE6 for ; Thu, 8 Jul 2021 06:06:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 54EB561CE6 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EBB3E6B0011; Thu, 8 Jul 2021 02:06:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E6AF06B005D; Thu, 8 Jul 2021 02:06:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE4EB6B006C; Thu, 8 Jul 2021 02:06:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id A89756B0011 for ; Thu, 8 Jul 2021 02:06:10 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E229122ADE for ; Thu, 8 Jul 2021 06:06:09 +0000 (UTC) X-FDA: 78338385258.02.DCD5433 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf16.hostedemail.com (Postfix) with ESMTP id 819F7F00008F for ; Thu, 8 Jul 2021 06:06:09 +0000 (UTC) Received: by mail-yb1-f173.google.com with SMTP id o139so7121442ybg.9 for ; Wed, 07 Jul 2021 23:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=t05u7OBgFdxDeppEwVUIqAGqylHaA/nLaL/wU/DSQ40=; b=aD0SS2OXs7Z+sHYgjvvvL4RQiDk0cFyYBZY4bVMbor6xhhynz0xNn+057DwiNYFYiV Xtl0HZfnqauDx+MkakBDZhj/+sc5VFZJZ9yyXGFMPExYM9JQGV5zyt1jBfWzElQAsbPL S8BY3LVvvgEGA7sug4s3RXyzwzQ0kTf3pe68e2P0GDJ12gN3tPdbqgqYzqKvpypY0vwv s2SRLVYkrMOqKouhuURTDvCboAY4Aa/kyosDNKXT2aQytrXea6PcQR/nxuTQUiudl11o fPjliOo8rxIlWPgBSmz8w6eZZ/Gb2hjl2EA5CIAXrgxdqn18G09O23Ax+YS72ItAvnJX z0Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t05u7OBgFdxDeppEwVUIqAGqylHaA/nLaL/wU/DSQ40=; b=aCksMSeRPYf97mIWk9lvhbw2dBgq8/4utn83p1bbZmmoYapLlKqlxB63fR4SP204fL 8wquPwQYpB5XwZFmKlrO3XPYqNkfUozvsa2lO2a4Ln9r8D+ApDISsb7uSi4mD5Sk+yOm ww5Z+XrpiDKwvzCl2U2ZMN3ymui9qXwjXnjC2dwV3vnqbA4G+0EOLfJYJ9UuWXSCoYlU bWB/CN9Q14xUHyvZa5sTflmB8siMnd4Aul4faqa0EkSejs+KvHoGxkdfzbo7ct0UO9y8 PcG2Lnhw3zYXnogZse+++0cF49laboQKjjCrrK6Sj3Y+7Vyb5kzg82fD+L8dduz2Wsso He3Q== X-Gm-Message-State: AOAM5332BGZYyLj7syLNEbP2VlH5YSM3SkeyOuSTgsXVlAR4kIb1GcGQ fBn7KIstzmvG1mwW5sqFmKA4m8FWjFlb9pZGLqwApg== X-Google-Smtp-Source: ABdhPJwuywcXCuuMFThvcecm/PDvMW0qWsJkICaNeWvKCBkZMZyzVkO4uVOwqu4pHud13EH10/evFaZ/KJv//5t1iLU= X-Received: by 2002:a25:4102:: with SMTP id o2mr35219483yba.23.1625724368500; Wed, 07 Jul 2021 23:06:08 -0700 (PDT) MIME-Version: 1.0 References: <20210623192822.3072029-1-surenb@google.com> <87sg0qa22l.fsf@oldenburg.str.redhat.com> <87wnq1z7kl.fsf@oldenburg.str.redhat.com> In-Reply-To: <87wnq1z7kl.fsf@oldenburg.str.redhat.com> From: Suren Baghdasaryan Date: Wed, 7 Jul 2021 23:05:57 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: introduce process_reap system call To: Florian Weimer Cc: Andrew Morton , Michal Hocko , Michal Hocko , David Rientjes , Matthew Wilcox , Johannes Weiner , Roman Gushchin , Rik van Riel , Minchan Kim , Christian Brauner , Christoph Hellwig , Oleg Nesterov , David Hildenbrand , Jann Horn , Shakeel Butt , Tim Murray , Linux API , linux-mm , LKML , kernel-team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=aD0SS2OX; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam05 X-Stat-Signature: do7yio1qhxiguq1dgjo96mgz4gefjyn4 X-Rspamd-Queue-Id: 819F7F00008F X-Rspam-User: nil X-HE-Tag: 1625724369-344592 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: On Wed, Jul 7, 2021 at 10:41 PM Florian Weimer wrote: > > * Suren Baghdasaryan: > > > On Wed, Jul 7, 2021 at 2:47 AM Florian Weimer wrot= e: > >> > >> * Suren Baghdasaryan: > >> > >> > The API is as follows, > >> > > >> > int process_reap(int pidfd, unsigned int flags); > >> > > >> > DESCRIPTION > >> > The process_reap() system call is used to free the memory = of a > >> > dying process. > >> > > >> > The pidfd selects the process referred to by the PID file > >> > descriptor. > >> > (See pidofd_open(2) for further information) > >> > > >> > The flags argument is reserved for future use; currently, = this > >> > argument must be specified as 0. > >> > > >> > RETURN VALUE > >> > On success, process_reap() returns 0. On error, -1 is retu= rned > >> > and errno is set to indicate the error. > >> > >> I think the manual page should mention what it means for a process to = be > >> =E2=80=9Cdying=E2=80=9D, and how to move a process to this state. > > > > Thanks for the suggestion, Florian! Would replacing "dying process" > > with "process which was sent a SIGKILL signal" be sufficient? > > That explains very clearly the requirement, but it raises the question > why this isn't an si_code flag for rt_sigqueueinfo, reusing the existing > system call. I think you are suggesting to use sigqueue() to deliver the signal and perform the reaping when a special value accompanies it. This would be somewhat similar to my early suggestion to use a flag in pidfd_send_signal() (see: https://lore.kernel.org/patchwork/patch/1060407) to implement memory reaping which has another advantage of operation on PIDFDs instead of PIDs which can be recycled. kill()/pidfd_send_signal()/sigqueue() are supposed to deliver the signal and return without blocking. Changing that behavior was considered unacceptable in these discussions. On the other hand using some kthread to do the reaping asynchronously has its disadvantages: userspace can't control the priority and cpu affinity of the thread doing the reaping and this work is not charged towards the caller. In the end a separate blocking syscall was deemed appropriate for this operation. More details can be found in the links I posted in the description of the patch. > > Thanks, > Florian >