Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3357853imu; Wed, 7 Nov 2018 09:05:49 -0800 (PST) X-Google-Smtp-Source: AJdET5cmcfXDJxCL0MzSRM92l9x+kGpp8nWHH+PyiI//NUs3V6ams1xpFZf4W41SezNCsvD5Hv+U X-Received: by 2002:a62:c42:: with SMTP id u63-v6mr1000071pfi.43.1541610349897; Wed, 07 Nov 2018 09:05:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541610349; cv=none; d=google.com; s=arc-20160816; b=MXf+eNzxD23fKlaXlTBL7ygtPROo22SjC6dPf6bVQBKVo583lYNm+x58poJ+XMs+9J cyxJS+x59eXNLvm7D9xCT3VaA72la1LpKifkqCJYDBjDGJNH75hPamHsRANwFlF2CD8k oTvhuecQOv6yw0l6VgBy7a+BqYThlUsc0qOpfmr8wKRx8me+9SP0yRjW1mQm86GIhviL 6SHlXy55ZmAjeSb839l7dxK+uoGCsDk8MAhIJYJxLOBvQdfsBOO0ocuUk149Rj8UyEnr xRl602JEacVgaoIfuyJbEouxNy0FzIf1Qd2/s54vcitwhzIPaIFyGbl9Ktq9cYRrqCZa xzzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=cNULmYAzYmx0kztq3Vd6BPqQyjJkJ91M1bGQaBy0c6c=; b=m6Tnm1U7gUNNM1rYO8bT4W5+nnXwpDjkgDDq2wiSWGV3zSzm5SMKK2IV+UCSS/u38T GyCYwyRR81Ocym4Mf46UgqE3J2p7T0lNKZYQQSF+8jH1p2TfplTGN524db+R08RcJKXc fQ0NeDR77Qf4F+Q/sZ4ppW8u+7UCxsKzeeQCQvNrVwKpIl5jw/4GLsVq2Mo3yGpSr2iw VMyr2MpxGulAXIA29d9IHadv/tA7L6SxeIFycGeqFIaT5eytGQ+KFOkDe8G9dPxmO84x kwr+MjaAYVK6R9dcPHTs6i5a/AbWszu1Zh00Fy2mK7o7npbmcI1+xOFBlBlX3kd5VZ6N DtDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r23si1058915pgu.359.2018.11.07.09.05.34; Wed, 07 Nov 2018 09:05:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731589AbeKHCgS (ORCPT + 99 others); Wed, 7 Nov 2018 21:36:18 -0500 Received: from mondschein.lichtvoll.de ([194.150.191.11]:52857 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727757AbeKHCgR (ORCPT ); Wed, 7 Nov 2018 21:36:17 -0500 Authentication-Results: auth=pass smtp.auth=martin smtp.mailfrom=martin@lichtvoll.de Received: from 127.0.0.1 (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lichtvoll.de (Postfix) with ESMTPSA id 5F61B3E8880; Wed, 7 Nov 2018 18:05:00 +0100 (CET) From: Martin Steigerwald To: Michal Hocko Cc: Daniel Colascione , linux-kernel , rppt@linux.ibm.com, Tim Murray , Joel Fernandes , Suren Baghdasaryan , Jonathan Corbet , Andrew Morton , Roman Gushchin , Mike Rapoport , Vlastimil Babka , "Kirill A. Shutemov" , "Dennis Zhou (Facebook)" , Prashant Dhamdhere , "open list:DOCUMENTATION" Subject: Re: [PATCH v2] Document /proc/pid PID reuse behavior Date: Wed, 07 Nov 2018 18:04:59 +0100 Message-ID: <4536090.43ZsV6LvYe@merkaba> In-Reply-To: <20181107160015.GI27423@dhcp22.suse.cz> References: <20181031150625.147369-1-dancol@google.com> <20181107160015.GI27423@dhcp22.suse.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michal Hocko - 07.11.18, 17:00: > > > otherwise anybody could simply DoS the system > > > by consuming all available pids. > > > > People can do that today using the instrument of terror widely known > > as fork(2). The only thing standing between fork(2) and a full > > process table is RLIMIT_NPROC. > > not really. If you really do care about pid space depletion then you > should use pid cgroup controller. Its not quite on-topic, but I am curious now: AFAIK PID limit is 16 bits. Right? Could it be raised to 32 bits? I bet it would be a major change throughout different parts of the kernel. 16 bits sound a bit low these days, not only for PIDs, but also for connections / ports. -- Martin